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ABSTBACT 



This thesis presents the design and implementation of a 
software protocol for the VAX-11/780, under the VMS oper- 
ating system, to allow message and file transfer to and from 

the IHTELI2C MDS system, under CP/M-80 operating system, via 

the Ethernet local area network. 

The design of this software protocol is based on the 
protocol hierarchies where the network is organized as a 
series of layers or levels, each one build upon its prede- 
cessor. The purpose of each layer is to offer certain 
services to the higher layers, shielding those layers from 
the details of how the offered services are actually 

implemented . 

With this design concept, the desired software protocol 
will be transportable in the sense that it can be used by 
different kinds of computer systems with minimal 

modifications. 

The Ethernet local area network is also designed in this 
same highly structured way. 
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I* INTHODD CTI ON 



4. EISCL4IMEB 

Many terms used in this thesis are registered trademarks 
of commercial products. Rather than attempt to cite each 
individual occurrence of a trademark, all registered trade- 
marks appearing in this thesis will be listed below, 
following the firm holding the trademark: 

INTEL Corporation, Santa Clara, California 
INTELLEC MDS 
Multibus 

CIGIIAL Research, Pacific Grove, California 
CP/M -80 

INTEELAN Corporation, Chelmsford, Massachusetts 

NI1010 Onitus Ethernet communications controller 
board 

NI3010 Multibus Ethernet communications controller 
board 

NS2030 VMS device driver and NI1010 diagnostic 
prcgra m 

DIGITAL Equipment Corporation, Maynard, Massachusetts 
VAX-11/780 Mini computer 
VAX/VMS operating system 

B. GENERAL DISCOSSICN 

This thesis presents the design and implementation of 
software protocol for the VAX-11/780, under VMS operating 
system, to allow message and fils transfer to and from 
INTELLEC MDS system, under CP/M-30 operating system, via 
Ethernet local area network. 
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The Ethernet board is the product of Interlan ccupany 
which has produced the hardware and software technology 
needed tc connect several makes of computers to the network. 
All ccmmunications between host computers are made through a 
coaxial cable which has a 10 megabit per second data ccmmu- 
nications rate. The Ethernet design is based on a highly 
structured protccol where the network is organized as a 
series of layers or levels, each one build upon its prede- 
cessor. The purpose of each layer is to offer certain 
services to the higher layers, shielding those layers from 
the details cf hew the offered services are actually imple- 
mented. 

This concept of design yields a lot of advantages in 
developing software protocol such that it can be used by 
different computer systems with the minimum of modifica- 
tions. It is anticipated that the software protocol designed 
will be general in nature in order to be used with ether 
computers using different operating systems with minor 
changes. The specific goals of this thesis are discussed in 
the next section concerning the background of the project. 

C. 6ACKGEG0ND 

The AEGIS weapons system simulation project currently 
being conducted at the Naval Postgraduate School is 
attempting to determine the feasibility of replacing the 
larger and relatively expensive main frame computer, the 
AN/UYK-7, with a system of 16 or 32 bit micro computers. 
Several significant real-time functions of the AEGIS weapons 
system are to be duplicated with associated data, inputs, 
timing, and supporting function so that a test example can 
be examined whose performance emulates that of the actual 
system. [Ref. 1.] 
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since the AEGIS weapons system simulation project 
involves many micro computers and since all of them must be 
real-time system, the speed of data communications between 
any two computers is very crucial. Thus, a high-speed means 
of communication is needed. 

Ethernet local area network is considered to be the 
solution because of its capability of permitting 10 megabit 
per second data communications between stations seperated by 
up to 25CC meters. Two NI3010 Multibus Ethernet communica- 
tion ccntrcller boards and a NI1010 Unibus Ethernet communi- 
cation controller boards were purchased and implemented in 
INTELIEC MDS systems and VAX-11/780, under the VMS operating 
system, respectively. An NS2030 device driver and an NI1010 
diagnostic program are also implemented in the VAX. 

The specific goals of this thesis are: 

1. To design and implement software protocol on the 
VAX/VMS such that it would be able to communicate (transfer 
messages and files) with the INTELLEC MDS system, under the 
CP/M operating system. 

2. To be used as a guideline in designing software 
protocols, especially when there is a need to communicate 
between VAX/VMS and other systems which use different oper- 
ating systems such as ISIS- II. 
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chapter II addresses the overall design philosophy of 
the software prctoccl which will be used in the VAX/VKS. 
Protoccl for a local area network is discussed in detail to 
include the relationship to the ISO open system interconnec- 
tion model. The design issues for the layers are enumerated 
to be a step-by-step guide in designing the protocol. 

Chapter III discusses the Ethernet Local Area Network, 
concise Ethrnet specification, and the NI1010 Unibus 
Ethernet Ccntroller Ecard. 

chapter IV explains the detailed design of the software 
protcccl tc include the use of the NS2030 Device Driver, how 
Ethernet Eoard and the Device Driver take care of the design 
issues fcr the layer mentioned in Chapter II, and steps in 
developing the application layer protocol. 

Chapter V summarizes the testing of the implemented 
software protocol and describe its capabilities. Suggestions 
are also given fcr future research and modification. 
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II. l^IC DESIGN CONCEPTS 



A. EHCTCCOL FOR LOCAL AREA NETWORK 

• Eac kgr ound 

A S€t of protocols spscifiss how nodes can comniuni- 
cate ever networks. Protocols are the procedures and conven- 
tions used to regiment the event progression required for 
orderly, mutually understood interaction between processes. 
Protocols are developed to satisfy qualitative and quantita- 
tive requirements fox process interconnection. A primary 
qualitative requirement is the "useful” work (i.e. , func- 
tionally) to be provided by the protocol. Other qualitative 
requirements include: 

a) . flex ibili ty (to accommodate new uses and features) 

b) . ccmpleteness (to properly respond to all relevant 

network conditions) 

c) . deadlock avoidance/backout mechanisms 

d) . synchreniza tion mechanisms (for interprocess control) 

e) .error detection and recovery 

f) . buffer overflow avoidance 

g) .message sequencing assurance 

h) . duplicate message detection and recovery 

i) . permeance (to implement the protocol uniformly through 

the local area network) 

j) .priority mechanisms 

k) . acccunting mechanisms 
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1) .security mechanisms 

ra). message delivery guarantees 

n) .data ccde/fcrmat transformations 

o) . computer equipment feature compatibility 

p) . operating system feature compatibility 

g) . ccmmunica ticns network feature compatibility 

Net all of these requirements are of equal impor- 
tance for each protocol implementation. For example, a 

protocol might inhabit a local area network node environment 
configured into any of the following topologies or hybrids 
of these topologies; 

a) .star topology - a centralized topology in which lines 
converge tc a central point or points (see Figure 
2. 1) ;this tcpolcgy is also called hierarchical cr tree. 



mesh 


topology 


- nodes 


are connected in an arbi 


trary 


pattern; each 


node can 


have multiple paths to 


ct her 


nodes 


• 








ring 


topology - 


the CO mmunications path is a loop 


w ith 


each 


node connected to 


exactly two other nodes 


in a 


given 


loop. 








bus 


topology - 


the nodes are connected along 


line 


segments; this 


topology 


is commonly found in Local 


area 


networks with a 


shared 


transmission channel such 


as a 


cable 


-bus . 









Typically, routing protocols for mesh topologies are much 
mere complex than routing protocols for the other tcpolo- 
gies. Thus, other protocol requirements, such as message 
delivery guarantees and message sequencing assurance, may be 
influenced by the tcpclogy chosen. 
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Figure 2.1 local Area Network Topologies. 

Cuar.titative requirements for protocols include: 

a) throughput - the volume of information that must be 
transferred during the peak period. This volume is 
usually characterized by mean message length in octets, 
the distribution of message lengths, and by the arrival 
rate of messages. 
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b) delay - the mean and maximum delay that the protocol 
will add to process responsiveness during the peak 
period. 

c) cost - naximum acceptable recurring and nonrecurring 
costs associated with the installation of a protocol in 
a local area network. 

A protocol may perform functions at the communica- 
tion link level or at application process level. Of primary 
concern to local area network application developers are the 
application level protocols. Some of the protocols which 
might be considered elementary to local area network devel- 
opments are discussed below. 

2 • A cp lica t ion subsys tem perspectiv e of e lem e nr ar v 

p rotoc ols 

The need for a number of elementary high-level 
protocols providing various types of services is apparent. 
Three main groupings of such protocols may be defined: 
appl icaticn-criented , executive-oriented, and network- 
induced. The motivation for this classification is the 
perspective of distributed systems as extensions of the 
single-system environment. The goal of elementary protocols 
is to extend the array of system utilities, programs and 
operating system services that are available on a single 
system to the total Iccal area network. Hence, development 
of elementary local area network protocols is a basic step 
in evclving high-level operating systems for local area 
networks. 

a. Ap pi :caticn-Ori ented Protocols 

Appl icat icn-ori ent ed protocols are defined to be 
interprocess communication rules and data formats which 
extend the commonly used system programs (languages. 
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editors, library, etc.) of one node to an application 
process in another node. Such protocols may include: 

1) .File Tra nsfer - allowing a process in one node to 

access files on another node as though the process were 
executing in that node. Similar to general system util- 
ities that supporr media conversion with and without 
blocking changes, format changes, naming changes, 
etcetera. 

2) . F ditc r - allowing a process in one node to store, 

modify and retrieve text information in a file at 
another node. Preferably the protocol is implemented to 
a specification consistently applied at each node on 
the network. 

3) . C ompile - allowing a process in one nods to produce 

executable programs at another node. The protocol 
implements a network wide source and object code 
library and linkage editor. 

♦ Is ■ allowing a process in one nods to invoke a 
program at another node by module name, to supply 
parameters to the program and to receive program output 
and system notice messages at the sending local area 
network node process. 

5) .Debug - allowing a process in one node to dynamically 
debug a program at another node. Preferably allows an 
application process distributed among two or more local 
area network nodes to be debugged interactively. 

b. Executive-Oriented Protocols 

Executive level protocols are defined to he 
interprocess communication rules and data formats which 
extend the operating system services (resource allocation. 
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device cr prcgram service, monitor services, etc.) of 
node to an application process in another node. 



;ne 



1) . Command P rct occl - allowing commonly used operating 

system services (ASSIGN, PRINT, TIME, STATUS, etc.) in 
each node cf a network to be invoked uniformly by a 
process in another node. 

2) -Virtual Scrolling Te rminal Pr otoco l - allowing a 

process in one node tc communicate with a process in 
another node as though the receiving process were a 
scrolling output device such as a printer or teletype. 

3) -Virtual Sc reen Termi n al Proto col - allowing a process 

in one node to communicate with a process in another 

node where the receiving process operates on a randomly 
addressable collection of two dimensional pages of text 
using predefined functions and transraitned variables. 

-Virtual Graphic Ter min al P roto col - allowing a process 

in cne node to communicate with a process in another 

node where the receiving process operates on a randomly 
addressable collection of two or three dimensional 
figures and two dimensional text using predefined func- 
tions and transmitted variables. 

c. Network-Induced Protocols 

Network induced protocols are defined to be 
interprocess communication rules and data formats which 
facilitate the operation of execurive level and application 
level protocols in a local area network. 

Endpoint Declaration Pr otoco l - provides the 
mechanism fcr a local area nerwork node to establish or 
disestablish addressable network ports in a directory 
thereby allowing qualified processes in other nodes to 
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become associat€d with processes assigned to this porr. 
The prctoccl might serve normal and previleged 
processes in the application space as wall as network 
control functions within the operating system. This 
prctoccl provides a mechanism to identify "well known" 
processes in a network directory. 

2) . N etwork A cce ss Autho r ization P rotocol - allowing a 

process to gain access to another process in the 
network. Includes log-on/log-off support to end users 
as well as general process in ter connection authoriza- 
tion. Interfaced with network security and privacy 
manacement information systems. 

3) . Network Di^^tor^ Service Proto col - allowing a process 

to request information about a node, another process or 
an end user. May also support custom menu services for 
each network user to promote the impression of a single 
integrated system. 

. Tra nsp ort Control Protocol - allowing a process in one 
node to establish an association with a process in 
another node and to exchange messages in a virtual 
circuit or datagram mode. Usually implemented as an 
augmentation to the operating system of a network node. 

5) . In ter proc ess S v nch ron iza tion - providing a mechanism 
for twc or more processes in two or more nodes to coor- 
dinate asynchronously executing functions. This 
prctoccl could underlie the virtual terminal control 
prctoccl. 

« Ne twork S yst em Control P rot ocol - providing the 
mechanism for establishing "built-in" maintenance and 
security subsystems in a local area network environ- 
ment. It is envisioned that performance, maintenance 
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and security checks should peraeate the local area 
network software as well as hardware system. This 
prctcccl facilitates unified specification of perfor- 
mance, maintenance and security related funcricns. 



B. PBOTCCOL HIEBARCHIIS 

To reduce their design complexity, most networks are 
organized as a series of layers or levels as mentioned 
earlier. 

Layer n on one machine carries on a conversation with 
layer n cn another machine. The rules and conventions used 
in this conversation are collectively known as the layer n 
protocol, as illustrated in Fig. 2.2 for a seven-layer 
network. The entities comprising the corresponding layers 
cn different machines are called peer processes. In ether 
words, it is the peer processes that communicate using 
prot ccol. 

In reality, no data are directly transferred from layer 
n on one machine to layer n on another machine (except in 
the lowest layer) . Instead, each layer passes data and 
control information to the layer immediately below it, until 
the lowest layer is reached. At the lowest layer there is 
physic al commu n i cation with the other machine, as opposed to 
the V Ir tual commun i cation used by the highest layers. In 
Fig. 2.2 virtual co mmunica tion is shown by dotted lines and 
physical ccmmunicaticn by solid lines. 

Between each pair of adjacent layers there is an i nter - 
face . The interface defines which primitive operations and 

services the lower layer offers to the upper one. When 
network designers decide how many layers to include in a 
network and what each one should do, one of the most impor- 
tant considerations is having cleanly defined intefaces 
between the layers. Having cleanly defined interfaces, in 
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1 



Host A Host B 




Figure 2.2 Layers, Protocols, and Interfaces. 

turn, requires that each layer perform a specific ccllecrion 
cf well urderstocd functions. In addition to minimizing the 
amount cf informa ticn that must be passed between layers, 
clean cut interfaces also make it simpler to replace rhe 
implementation of one layer with a completely different one, 
because all that is required of the new implementat icn is 
that it offers exactly the same set of services to its 
upstairs neighbor as the old implementation did. 
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Ihs set of layers and protocols is called the ne twor k 
a ch itectu re [Ref. 2. ]. The specification of the architec- 
ture must contain enough information to allow an implementer 
to writs the program for each layer so that the program will 
correctly obey the appropriate protocol. Neither the details 
of the iiplementat ion nor the specification of the inter- 
faces are part of the architecture. In fact, it is not even 
necessary that the interfaces on all machines in a network 
be the same, provided that each machine can correctly use 
all the protocols. 

C. DESIGN ISSUES FOB THE LAYEBS 

Some of the key design issues that occur in computer 
networking axe present in several layers. The following are 
some of the common problems that must be repeatedly dealt 
with in the design of the different protocols. 

1. Every layer must have a mechanism for connection estab- 
lishment. since a network normally has many computers, 
some of which have multiple processors, some means is 
needed for a process on one machine to specify who it 
wants to talk to. In any layer where there are multiple 
destinations, addressing is needed. 

2. Closely related to the mechanism for establishing 
connections across the network is the mechanism for 
terminating them once they are no longer needed. 

3. Another set of design decisions are the rules for data 
Transfer. Does data only travel in one direction, called 
simplex communication, or can data travel in either 
direction, but not simultaneously, called half- d uple x 
communication, cr can they travel in both directions at 
cnce, called f ul l-dup lex communication? The protocol 
must also determine how many logical channels the 



22 



ccnnsction ccrresfcnds to, and what their priorities 
are. Many networks provide at least two logical channels 
per ccnnecticn, cne for normal data and one for urgent 
data. 

h.Zrrcr control is an important issue when the physical 
communication circuits are not perfect. Many error- 
detecting and error-correcting codes are known, but both 
ends of the connection must agree on which cne is being 
used. In additicn, the receiver must have some way of 
telling the sender which messages have been correctly 
received and which have not. 

5. Not all communication channels preserve the cider of 
messages sent on them. To deal with a possible loss of 
sequencing, the protocol make explicit provision for the 
receiver to allow the pieces to be put back together 
properly. 

6. An issue that occurs at every level is how to keep a 
fast sender from swamping a slow receiver with data. 
There are various solutions to this and all of them 
involve some kind of feedback from the receiver tc the 
sender, either directly or indirectly, about what toe 
receiver's current situation is. 

7. Another problem that must be solved repeatedly at 
different levels is the inability of all processes to 
accept arbitrarily long messages. This leads to mechan- 
isms for disassembling, transmitting, and then reassem- 
bling messages. 
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D. THE ISO REEBRENCi MODEL 

This nicdel is closely based on a proposal develops! by 
the International standard Organizarion (ISO) as a first 
step toward international standardization of the various 
protocols. 

The Reference Model of Open System Interconnection has 
seven layers as shown in Fig. 2.3. 



Layer 

7 



Name of unit 
exchanged 




Me s sage 



Message 



Message 



Message 



Figure 2.3 ISO Reference Model. 
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The principles that ISO applied ro arrive at the seven 
layers are as follows; 

1. A layer should be created where a different 
level of abstraction is needed. 



2. Each layer should perforni a well defined 

function. 



3. The function of each layer should be chosen 
with an eye toward defining internationally standardized 
protocols . 



4. The layer boundaries should be chosen to 
tninimize the imformation flow across the interfaces. 

5. The number of layers should be large enough 
that distinct functions need not be thrown together in the 
same layer cut of necessity, and small enough that the 
architecture does not become unwieldy. 



The seven layers, from the lowest layer to the highest 
layer, are; 



1 . Physical layer - The physical layer provides 
mechanical, electrical, functional and procedural 
char acter istics to establish, maintain, and 
release physical connections (e.g., data-circuirs) 
between link-entities. The physical layer provides 
for the transmission of transparent bit streams 
between data link layer protocols across physical 
connections which are permanently' or dynamically 
establis hed. 



2.^ta Link Laye r - The purpose of the data link 
layer is tc provide the functional and procedural 
means to establish, maintain, and release one or 
mere data links among network-entities. This layer 
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masks the characteristics of the physical layer 
(such as switched, multipoint, broadcast, polling, 
contention, etc.) from the network layer. 

3«^iwcrk Laye r - The network layer provides func- 
tional and procedural means to exchange network- 
services-data- uni ts between two transpor t-entit ies 
over a network-connection. It provides transport- 
entities with independence from routing and 
switching considerations, including the case where 
a tandem subnetwork-connection is used. The 
network layer protocol uses underlying data link 
connections to make network connections invisible 
tc the transport layer protocol. 

4. Tr a nspor t Lave r - The transport layer exists to 
provide a universal transport service in associa- 
tion with the underlying services provided by 
lower layers. The transport-service provides 
transparent transfer of data between session- 
entities. The transport-service relieves these 
session-entities from any concern with the 
detailed way in which rel i able and cost-effective 
rans f er cf data is achieved. Three types of 
ranspcrt services are: 

- A connection-oriented service 

- A tr ansact ion- oriented service 

- A broadcast-oriented service 

The transport service is required to optimize the 
use of the available communications services to 
provide the performance required for each ccnnec- 
tion between sessicn-enti ties at a minimum cost. 
To achieve optimization, the global demands of all 
concurrent transport users and the transport layer 
resource limitations are considered. 
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5 . Sess ion l aye r - The purpose of the session layer 
is to assist in the support of the interactions 
between coorperating presentation-entities. To do 
rhis, the session layer provides servioes which 
are classified into the following two categories: 

a) Session Administration Services 
binding two pr esentation-enrities into 
a relationship and unbinding them. 

b) Session Dialogue Service - ccnrrol of 
data exchange, delimit and synchron- 
izing data operations between two 
pr ese nt a tion-en titles. 

6 . Pre s an t ation La yer - The purpose of the presen- 
tation layer is to provide the set of services 
which may be selecred by the application layer to 
enable it to interpret the meaning of the data 
exchanged. These services are for the management 
of the entry, exchange, display and control of 
structured data. The presentation-service is loca- 
tion independent and is considered to be on top of 
the session layer which provides the service of 
linking a pair of presentation-entities. It is 
through the use of services provided by the 
presentation layer that applications in an open 
systems interconnection environment can communi- 
cate without unacceptable costs in interface vari- 
ability, transformations or application 

modification. There are four phases of presenta- 
tion layer protocol operation: 

a)Session establishment phase in which 
the connection is set up. 
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t) Presentation image control phase in 
which the pressnration options can be 
selected by value, by name, by prior 
agreement or by negotiation. 

c) Data transfer phase which controls the 
data structure accesses and perhaps 
executes special purpose transfcrma- 
ticns such as voice compression or 
data encryption. 

d) Termi nation phase 

7 . Appl icat icn Lay er - This is the highest layer in 
the reference model of open systems interconnec- 
tion architecture. Protocols of this layer 
directly serve the end user by providing the 
distributed information service appropriate to an 
application, to its management and to the system 
management. Management of open systems interccn- 
nection comprises those functions required to 
initiate, maintain, terminate and record data 
ccncerning the establishment of connections for 
data transfer among application processes. The 
ether layers exist only to support this layer. 
Three categories of application layer protocols 
are defined: 

a) System Management Protocols - respon- 
sible for controlling and supervising 
open systems (e.g., initiating 
dialo g) . 

b) Application Management Protocols 
responsible for controlling and super- 
vising application processes (e.g,, 
access control) . 
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III. E TBER HBT LOCAL AREA NETWORK 



A. OVERVIEW 



Ethernet is one type of local communication network 
which makes use of coaxial cable as a mean to transfer data. 

t > 




Contention 

interval 



Packet 



D[ 



Packet 



Idle 



Time 



Figure 3- 1 Contention, Transmission, and Idle States. 



All stations in the Ethernet network monitor the cable (the 
ether) during their cwn transmission, terminating transmis- 
sion immediately if a collision is detected. 

The Ethernet mechanism is modeled in Fig. 3. I. At the 
point marked t© a station has finished transmitting its 
packet. Any other stations having a packet to send may now 
attempt to do so. If two or more stations decide to transmit 
simultaneously, there will be a collision. Each will detect 
the ccllisicn, abort its transmission, wait a random period 
of time, and then try again, assuming that no other station 
has started transmitting in the mean time. Ethernet will 
therefore consist of alternating contention and transmission 
periods, with idle periods occurring when all stations are 
guiet . 
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B. CCHCISE ETHEBNET SPECIFICATION 
1 f F crma t 



I 

I 

PREAMBLE 

I 

1 

64-BITS 



DESTINATION 

ADDRESS 


SOURCE 

ADDRESS 


TYPE 


DATA 


FRAME 

CHECK 

SEQUENCE 



48-BITS 16-BITS 46-1500 BYTES 



INTERFRAME 
SPACING I 



32-BITS 9.6 MICROSEC. j 



Figure 3.2 Ethernet Packet Format. 

A station trust be able to transmit and receive packets on 
the ccmmcn coaxial cable with the indicated packet format 
and spacing. Each packet should be viewed as a sequence of 
8-bit bytes; the leasr significant bit of each byte 
(starting with the preamble) is transmitted first. 

3^) • ® S ize : 1526 bytes(8 byte preamble + 14 

byte header 1 500 data bytes 4 byte CRC) 

» Mit^gng P a c ke t Size : 72 bytes (8 byte preamble + 14 

byte header 46 data bytes ♦ 4 byte C3C) 

c) . Pre amb le: This 64-bit synchronization pattern contains 

alternating 1's and O's, ending with two consecutive 

Vs. 

« Cestin ati cn A ddress : The 48-bit field specifies the 

station (s) to which the packet is being transmitted. 
Each station examines this field to determine whether 
it should accept the packet. The first bit transmitted 
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indicates the type of address. If it is a 0, the field 
contains the unique address of the one destination 
station. If it is a 1, the field specifies a logical 
group cf recipients; a special case is the broadcast 
(all stations) address, which has all 1 ' s. 

s) *Scurc^ This 48-bit field contains the unique 

address of the station that is transmitting the packet. 

f) .Tyce Fi^d: This 16-bit field is used to identify the 

higher level protocol type associated wrth -he packer. 
It determines hew data field is interpreted. 

9) ‘ilil field contains an integral number of 

bytes ranging from 46 to 1500. (The minimum ensures 
that valid packets will be distinguishable from cclli- 
sicn fragments.) 

h) Se quence : This 32-bit field contains a 

redundancy check (C3C) code, defined by the generating 
pelynomial ; 

+Xl0+x®+x^+x5+x^+x2+x+1 

The CRC covers the address (destination/source) , type, 
and data fields. The first transmitted bit of the desti- 
nation field is the high-order term of the message 
pclyncmial to be divided by G(x) producing remainder 
S (X) . The high-order term of R (x) is the first trans- 
mitted bit of the Packet Check Sequence field. The algo- 
rithm uses a linear feedback register which is initially 
preset to all 1's. After the last data bit is trans- 
mitted, the contents cf this register (the remainder) 
are inverted and transmitted as the CRC field. After 
receiving a good packet, the receiver's shift register 
contains 11000111 00000100 11011101 01111011 (x^i... 

,xO) . 
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-) • WinimuS Spaci n q: This spacing is 9.6 microse- 

cond, The minimuir time that must elapse after one tran- 
smissicn before another transmission may begin. 

j) . Bound -Tri p Delay: The maximum end-to-end, round-nrip 

delay for a bit is 51. 2 microsecond. 

It) ♦Ccllisio Filte ring : Any received bit sequence smaller 

than the minimum valid packet (wirh minimum data field) 
is discarded as a collision fragment. 

2 . Ccn tro l Proc e dur e 

The control procedure defines how and when a host 
szaticn may trasmit packets into the common cable. The key 
purpose is a fair resolution of occasional contention among 
transmitting stations. 

a) .Defer: A station must not transmit into the coax cable 

when the carrier is present or within the minimum 
packet spacing time after the carrier has ended. 

♦ Tran smit: A station may transmit if it is not defer- 

ring. It may continue to transmit until either the end 
of the packet is reached or a collision is detected. 

c) .Abort: If a collision is detected, transmission of the 

packet must terminate, and a (4-6 bytes of arbi- 

trary data) is transmitted to ensure that all ether 
participants in the collision also recognize its occur- 
rence . 

. R et r an smit ; After a station has detected a ccllision 
and aborted, it must wait for a random ret ra nsm i ssion 
defer as usual, and then attempt to retransmit 
the packet. The random time interval is computed using 
the backoff algorithm (below). After 16 ret ransmission 
attempts, a higher level (e.g. software) decision is 
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irade tc determine whether to continue or abandon the 
effort. 



®) . Backoff; Retransmission delays are computed using the 
Tr unca ted Binary Exp o n en tial Ba ckof f algorirhm, with 
the aim of fairly resolving conrention among up to 1024 
stations. The delay (the number of time units) before 
the n^*" attempt is a uniformly distributed random number 
from 0 to 2 for 0<n<10 (n = 0 is the original attempt) . 
For attempt 11-15, the inrerval is rruncated and 
remains at 0 to 1023. The unit of time for rhe retrans- 
mission delay is 512 bit times (51.2 microsecond). 

3 • ChSi-I:® 1 Enc od ing 

Manchester encoding is used on the coaxial cable. It 
has a 50^ duty cycle, and insures a transition in the middle 
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Figure 3.3 Data Rate Scheme. 

of every bit cell (’’data transition'*)- The first half of 
the bit cell contains the complement of the bit value, and 
the second half contains the true value of the bin. 
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4. Cata Rate 



Data rate is 10 Mbit/sec = 100 nsec bit call ± 



o.on. 



5 ♦ Car rie r 

The presence of data transitions indicates that 
carrier is present. If a transition is not seen between 
0.75 and 1.25 bit times since the center of the last bit 
cell, then carrier has been lost, indicating the end of a 
packet. Fcr purposes of deferring, carrier means any 
activity cn the cable, independent of being properly fcrmsd. 
Specifically, it is any activity on either receive or cclli- 
sion detect signals in the last 160 nsec. 

6 . Ccax Ca b le 

« Impe da nce; 50 chms ± 2 ohms (Mil Std. C17-H) . This 
impedance variation includes batch-to-batch variations. 
Periodic variations in impedance of upto ± 3 ohms are 

permitted along a single piece of cable. 

Loss ; The maximum loss from one end of a cable 
segment to the ether end is 8.5 db at 10 MHz (equiva- 
lent tc ®500 meters of low loss cable) . 

c) . S hield ing ; The physical channel hardware must operate 

in at ambient field of 2 volts per meter from 10 MHz to 
30 MHz and 5 volts per meter from 30 MHz to 1 GHz. The 
shield has a transfer impedance of less than 1 millichm 
per meter over the frequency range of 0. 1 MHz to 20 MHz 
(exact value is a function cf frequency) . 

d) .Ground Con necti on: The coax cable shield shall net be 

connected to any building or AC ground along its 
length. If for safety reasons a ground connecticn of 
the shield is necessary, it must be in only cne place. 
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xoi. 



e) . Phy sical D imen s icQS : This specifies the dimension of a 

cable which cat be used in the s tan dard tap- ether 
cables may alsc be used, if they are net to be used 
with a tap-type transceiver (such as used with connec- 
torized transceivers, or as a section between sections 
tc which standard taps are connected) . 



Center Conductor: 
Core Material: 

Cor e 0. D . : 

Shield: 

Jacket: 



Jacket C. E. : 



0.0355” diameter solid tinned copper 
Foam polyethylene or foam teflon FF? 
0.2U2" minimum 
0.326” maximum shield O.D. 

PVC or teflon ?3? 

0. 405” 




Figure 3.4 Coax Cable, Connectors, and Transceivers. 



7 • Coax Con rectors ap^d Te rm inators 

Coax cables must be terminated with male N-ssries 
connectors, and cable sections will be joined with female- 
female adapters. Connector shells shall be insulated such 
that the coax shield is protected from contact to building 
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grounds. ft sleeve cr boot is acceptable. Cable segments 
should be terminated with a female N-series connector (can 
be made up of a barrel connector and a male terminatcr) 
having an impedance cf 50 ohms * and able to dissipate 1 

watt. The outside surface of the terminator should also be 
insulated . 

8 • T ra n sceive r 

Up tc 100 transceivers may be placed cn a cable 
segment nc closer than 2.5 meters. Following this placement 
rule reduces to a very low (but not zero) prcbabiliry the 
chance rhat ob jecticnable standing waves will result. The 
details cf transceiver interface and coax cable interface 
can be fcund in Interlan's "Concise Ethernet Specification" 
[Bef. 3]. 

C. BI1010 ONIBOS ETBEBNET COMBONICATIONS CONTROLLSB 
1 . Fea tur es 

Link Laver Fun c ti o ns : 

1) .Data Sncapsulation/decapsulat ion 

2 ) .Carrier Sense Multiple Access/Collision Detected 

(CSMA/CD) transmit and receive data link management 

b) . Ethernet P h ysi c al C han nel Funct ions; 

1) . 10 Mbits per second data rate 

2) . Data encoding and decoding 

3) . Channel access 

h) .Transceiver cable interface 

c) •Jsiwork Sta tist ics; 

1) .Tallies number of transmissions, receptions, errors, 
and collisions 

<i) « Perfor man ce ; 
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1) .16 Kbytes FIFC buffer for back-to-back frame recep- 

tion 

2) . 2 Kbyte FIFO buffer for frame transmission 

2). DMA transfers to/from unibus memory 

°) ♦ Ex tensive Diagnosti c F eat ure s; 

1) . internal and external data loop-back operation 

2) . Network LED indicators 

3) .Ecwer-up confidence test 

4) .Fass/fail LSD indicator 

5) , Diagnos tic software provided 

f) • Cne Ee x-Hight B eard ; 

1).Fit one unibus SPC slot 

2 . Desc riptio n 

The Nil 010 Onibus Ethernet Communication Controller 
Board is a single Hex-height board that contains all the 
data communications controller logic required for inter- 
facing DEC'S family of VAX- 11 and Unibus-based PDP-11 mini- 
computers to rhe Ethernet local area network. It performs 
the specified data link and physical channel functions, 
permitting Onibus-based systems to engage in transmission 
and reception of data with other Ethernet stations on the 
local area network with the speed of 10 Mbit per second and 
wirh the maximum distance of 2500 meters. As shown in Figure 
3.5, the NI1010, when attached to a transceiver unit, 

provides a VAX-11 or Unibus-based PDP-11 a complete connec- 
tion onto the Ethernet local area nerwork. 

3 . Jt hern e t data link lay er f un c tions 

Within the data link layer the NI1010 performs the 
specified Ethernet transmitter processes of Transmit Data 
Encapsulation and Transmit Link Management, and the Ethernet 
receive processes of Beceive Data Decapsulation and Heceive 
Link Management. 
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Figure 3.5 Ethernet Architecture and Implementation. 

a. Transmit data encapsulation 

Figure 3.6 shows the Ethernet Frame Format for 
packet transmissions over the coaxial cable physical 

channel. For receive synchronization purposes, the frame is 
preceeded with a 64-bit preamble sequence and terminated 
with a minimum interframe spacing period of 9.6 
microseconds . 
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The Destination Address field specifies the 
station (s) for which the frame is intended. The address 
value provided by the user may be either; 1)the physical 
address of a particular station on the network; 2) a 
mult icast-grcu p address associated with one or more 
stations; or 3) the broadcast address for simultaneous tran- 
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Figure 3.6 Ethernet Frame Format. 

smissicn to all stations on the network. The first bit of 
the Destination Address distinguishes a physical address 
from a multicast address (0 = physical, 1 = multicast) . For 
broadcast transmissions an all one-bit pattern is used. 

The Source Address field specifies the physical 
address cf the transmitting station. To eliminate the possi- 
bility of an addressing ambiguity on a network, associated 
with each SI1010 is a unique 48-bit physical address value 
assigned to it at the time cf manufacture. On transmission, 
the MI1010 inserts this value into the Source Address field. 

The type field is specified by the user for use 
by high level network protocols. It specifies to the 
receiving station(s) how the content of the Data field is to 
be interpreted. 
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The Data field may contain a variable number of 
data bytes ranging from a minimum of 46 bytes to a maximum 
of 1500 bytes. The NI1010 accepts less than 46 bytes from 
the user by automatically, inserting null characters to 
complete a 46-byte minimum frame size. 

The Frame Check Sequence (FCS) field contains a 
32-bit cyclic redundancy check (CRC) value generated by the 
NI1010 during transmission. 

b. Transmit link management 

The Nil 0 10 performs all Ethernet Transmit Link 
Management functions required to successfully deliver a 
frame onto the network. These functions include: 

• Carrier Deference; the NI1010 monitors the physical 
channel and defers its transmission should the channel 
be busy carrying ether traffic; 

• Collision Detection; once the NI1010 has finished defer- 
ring to the passing traffic on the network, it proceeds 
with its own transmission. In the event that another 
station simultaneously began a transmission, a "cclli- 
sicn" occurs. The NI1010 detects this event and termi- 
nates its transmission attempt; and 

• Ccllisicn Backoff and Retransmission ; when a transmis- 
sion attempt has been terminated due to a collision the 
NI1010 attempts its transmission again after delaying a 
short random period of time. The scheduling of the 
retransmission is determined by the Ethernet process 
called "truncated binary exponential backoff". The 
NI1010 reports an error should it be unable to deliver 
its frame onto the network after 16 transmission 
attempts. 
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Receive data decapsulation 



c . 



When not transmitting a frame the NI1010 conti- 
nuously listens to the traffic being carried on the network. 
After synchronizing to the preamble sequence of a frame on 
the network, the NI1010 processes the Desrination Address 
field through its address filter logic to determine whether 
or not the incoming frame is intended for it. The Nil 010 
controller will only accept a frame from the network with a 
Destination Address value that either; 

1) matches the physical address of the NI1010 board 
itself; 

2) contains the broadcast address; or 

5) matches one of the 63 multicast-group logical 
addresses which the user may assign to the board. 

The Nil 0 10 performs high speed multicast-group 
address recognition. Whenever a multicast-group logical 
address is received on the network, the NI1010 converts the 
frame's 48-bit Destination Address field into a 6-bit table 
entry pointer through the application of a many-tc-few 
mapping called "hashing". It uses the resulting pointer to 
look into a table of valid multicast-group addresses to see 
if the received address is one that the station should 
accept. 

For network management and diagnosis, the NI1010 
may be operated in a "promiscuous" receive mods. When in 
this mode, the NI1010 disables its address filter logic and 
accepts all undamaged frames passing on the network. 

The Nil 0 10 validates the integrity of a received 
frame by regenerating the 32-bit CRC value on the received 
bit stream and comparing it against the CRC value found in 
the frame's Frame Check Sequence field. 
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3. Receive link management 



Since collisions are a normal occurrence in the 
Ethernet's CSMA/CD link management process, the HI1010 
receiver filters out collision fragments from valid frames. 

^ • Ethem et phys ica l 1 a^er f unct ion s 

Within the Ethernet Physical Layer the NI1010 
performs the electrical and procedural specif icaticns 
required fcr interfacing directly to a transceiver unit. 
Transmissions and receptions take place at a 10 Mbits per 
second data rate under half-duplex operation. 

a. During transmission the NIIOIO's physical 
channel functions include: 

1 ) . Generating the 64-bit preamble sequence for all 

receivers on the network to synchronize on; 

2) . Parallel to serial conversion of the frame; 

3) . Calculating a 32-bit CRC value and inserting it into 

the Frame Check Sequence field; 

4 ) . Generaring a self -sy nchronizing serial bit stream 

through Manchester encoding of the data; and 

5) . Providing proper channel access by detecting carrier 

from another station's frame transmission, and sensing 
the collision presence signal from the transceiver 
unit. 

b. The NIIOIO's physical channel functions during 
reception include: 

1 ). Manchester decoding the incoming bit stream into a data 
stream and a deck stream; 
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2) . Synchrciuzing to, and removal of, the preamble 

sequence; and 

3) . Serial to Parallel conversion of the frame. 

5 • P erfor mance 

The NI1010 has been designed to offer high network 
performance while minimizing the service loads placed upon 
the host Unitus system. 

Serving to buffer the system from the unpredictable 
interarrival times char act eristic of network traffic, the 
board has a FIFO (first-in, first-out) memory which can 
store up to 16 Kbytes of received frames. Because of this 
extensive front-end buffering, few time-critical service 
requirements are imposed on the host Unibus system. 

Fcr transmission, the NI1010 has a 2 Kbyte Transmit 
FIFO which permits the host to perform a one-time transfer 
of a frame. 

All data block transfers between the Nil 010 and 
Unibus memory are performed under the control of an onboard 
DMA controller. To maximize system performance during recap- 
tion, the controller allows the user to preload up to 
sixteen different memory buffer address and byte count 
values fcr DMA of received frames. 

6 • sns i V e Di agnosti c Fe atu res 

The NI1010 offers comprehensive network and beard- 
level diagncstic tools which greatly simplify the process of 
identifying a network communication problem. Mounted on the 
edge of the board are four network state LED indicators 
which provide a visual indication of whether or not the 
user's station is communicating onto the network. For a 
comprehensive station diagnosis, the user can exercise the 
NIIOIO's cenm unicaticn facilities in either internal or 
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Figure 3.7 NI1010 Functional Diagram. 

external data loopback mode; making it possible to detect 
and isolate a fault to rhe coaxial cable, transceiver unit, 
transceiver cable; or the NI1010 board itself. 

Cn power-up the Nil 010 performs a confidence test of 
the cnbcard memories, register and data paths. A L2D indi- 
cator shows the pass/fail operational state of the board. 

• Net work st at i stics 
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d) .nunit€r of frames transmitted 

e) . number of transmit collisions 



For detailed description of NI1010 Ethernet 
Communication Controller Board, see NI1010A Unibus Etherner 
Communications Controller User Manual [Ref. 4]. 
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IV. DETillED DESIGN AND I M PLEBENTATIO N 



A. DESIGN ISSOES CONSIDERATION 

After studying the NI1010 Unibus Ethernet Communicaticns 
Contrcller in detail, some of the common problems with the 
design of protocol mentioned in Chapter II can be solved as 
follows: 

1. The le-hod needed for a process on one machine to 
specify who it wants to tallc no is rhe Destination 
Address and the Source Address field in every trans- 
mitted frame. 

2. There is no need to find a mechanism for terminating the 
connection across the network, since the Ethernet will 
put itself to the idle state automatically if there is 
no carrier on the coax cable. 

3. The rule for data transfer is fixed on the half-duplex 
operaticn, i. e. , the data can travel in either direction, 
but not simultaneously. 

U.Fcr the error control issue, Ethernet frame format 
provides a 32-hit Frame Check Sequence field which 
contains Cyclic Eedundancy Check (CRC) value. This 
value is generated by the Ethernet board of the sending 
station and will be checked by the board of the 
receiving station. 

5. The problem of how to keep a fast sender from swamping a 
slow receiver with data is solved by the 16 Kbyte FIFO 
Receive buffer on all Ethernet boards. 
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6. Ethernet board performs data link layer in transmitting 
data encapsulation and receive data decapsulation. The 
data field of the frame format can vary from 46 to 1500 
bytes. Thus, the design issue of the ability of 
processing arbitrarily long messages is solved. 
Furthermcre , if the data is less than 46 bytes, the 
board will automatically insert null characters to 
complete a 46-byte minimum frame size. 

However, the problem of preserving the order of messages 
is net solved by the capability of the Ethernet board. The 
design of a higher layer protocol would have to take this 
issue into consideration. The forthcoming sections will 
explain hew to create a design such that it will overcome 
this problem. 

The NI1010 Unibus Ethernet Communications Controller 
Board together with the Transceiver represent the first two 
layers. Physical Layer and Data Link Layer, of the ISO 
aeference Model as shown in Figure 4.1. 

E. SS2030 DEVICE DRIVER 
1 . Cve rvi e w 

The NS2030 product includes a diagnostic program and 
a VAX/VMS device driver source, hereafter referred to as 
NIDRI7EH, that allows a suitably privileged application 
program written in VAX- 11 MACRO assembly language or any 
VAX/VMS high level language (such as VAX-11 FORTRAN) to 
interface to INTERLAN’s Unibus to Ethernet interface, the 
NI1010. The application program uses standard VAX/VHS 
services to interface to the Ethernet. There are nc new 
interfaces tc learn. NIDRIVER supports all features of the 
NI1010 ccntroller, including full duplex operation (trans- 
mitting with receives outstanding) , non-con tiguous buffers 
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Figure 4.1 NI1010 and ISO Beferenca Model. 

for transmission and reception (often called "scatter/ 
gather" cr "buffer chaining"), and the extensive onboard 
intelligence and diagnostic functions. The standard QIO 
interface allows the network software designer to choose 
among several techniques for performing I/O: synchrcncus 

I/O using the SQIOW system service, and asynchronous I/O 
using the $QIO system service with event flags and/or AST 
routines. 
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with one $QIC request, an application program is 
able to instruct the NI 1010 to obtain a prefcrmatted 
Ethernet packet out of system memory and transmit it onto 
the Ethernet, similarly, with one IQIO request, the program 
can specify the address and length of a buffer in system 
memory into which the controller can place the next received 
packet. Single $QIC requests can also be used to perform 
other NI1010 functions such as GO ON-LINE, RUN DIAGNOSTICS, 
REPORT STATISTICS, and LOAD GROUP ADDRESS (ES). 

The detailed description of NIDRIVER is contained in 
the Interlan NS2030 VAX/VMS (TM) Device Driver and 
Diagnostics User Manual [Ref. 5]. 

2 • Pro qra m inte i faces to N IDRI VER 

Detailed descriptions of the following standard 
VAX/VHS system services can be found in the VAX/VMS System 
Services Reference Manual [Ref. 6] and in the VAX/VHS I/O 
User's Guide [Ref. 7]. Some of the very important system 
services are also included in Appendix A. 

a. Using Sassign (associate channel) with NIDRIVER 

Before a program can issue requests to NIDRIVER, 
it must assign a channel to the NI1010 controller. The 
Assign I/O Channel (SASSIGN) system service is used to 
assign a channel to a device. You supply the device name as 
part of the ^ASSIGN call: $ASSIGN returns a channel number. 

The NI1010 controller device name supported by NIDRIVER is 
of the form NIxy: Because the NI1010 controller represents a 
single "unit" (in the VMS I/O sense) , the first controller 
is called "NIAO:", the second "NIBO:", and so on. 
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b. Using SAIIOC (allocate device) with NIDRIVZR 



A process can allocate a device for its exclu- 
sive use using the SALLOC system service. Once the device is 
allocated, no other process (except for subprocesses related 
to the issuing process) can assign a channel to the device. 

Because the Nil 010 controllers provide low level 
access to the Ethernet. NIDEIVER supports each controller as 
a non-sharable device. When a process assigns a channel to 
an NI1010 ccntrcller, VAX/VNS performs an impl icit SALLOC 
for the process. 

c. Using SGETCHN and SGETDEV (get device 
Informa ticn) 



Two system services can be used to obtain infer- 
maticn atcut NIDEIVER: Get Channel Information (SGETCHN) and 
Get Device Information (SGETDEV). SGETCHN is used to obtain 
information about a specific device. 

When used to obtain information about an Nil 010 
controller, these system services return identical primary 
and secondary device characteristics. 

d. Using SQIO and SQIOW (request I/O function) 



Because NIDEIVER supports the standard VAX/VHS 
QIO interface, all controller requests follow the general 
CIO format: 



$QIC_S [efn ] ,chan ,func,[ iosb],[astadr],[ astprm ], 
Cp13.Cp2],Cf33.Cp^].Cp5],[?6] 

The first six arguments are device/f unction 
independent and can be used in any controller I/O request. 
For example, you can specify an AST routine address (the 
"astadr" argument of the QIO request) if you need to execute 
special code at I/O completion. 
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Dsv ice/f unction dependent arguments ?1 and P2 
must be supplied for all controller operation that use the 
DMA channel for transferring data to or from VAX memory. P1 
is the (virtual) address of a WORD-ALIGNED buffer. P2 is the 
size of the buffer in bytes and must be e ven and less than 
1536 (decimal). Parameter P3 through P6 are ignored in 

NI1010 operations. 

func t ion s. To fully understand the 
I/O functions supported by NIDRIVSR, one should kncv how 
VAX/VMS I/O functions are encoded into 16-bit values (the 
function argument of the QIO request) . I/O function values 
have the following fcrmat: 

15 6 5 0 

+ + +• 

function modifiers code 

+ + 1 - 

The low-order 6 bits of the function value 
are a code that specifies the particular operation to be 
performed. The high-crder 10 bits of the function value are 
function modifiers and are normally used to alter the parti- 
cular operation specified by the cods. Symbolic names for 
function codes and modifiers are defined by the SIODEF 
macro, as described in the VAX/VMS System Services Reference 
Manual [Ref. 6]. fl modified function can be invoked by 
"0R'*ing a function code and function modifier. For example: 

lOS^SETMODE! IO$_SHUTDOWN 
in MACHC assembly language, or 

10$ SETMODE .OR. 10$ SHUTDOWN 



in FORTRAN. 



52 



The following describes each I/O function 
supported by NID5IVSR. 

10$ SETM ODE! I0jL.START0P 

Issuing a QIO with a ••func" argument of 
IO$_SETMOEE!IO$_STASTOP causes NIDRIV2R to begin cor.trcller 
cperaticn. NIDRIVER will allocate necessary VAX/VHS 
resources and pass a GO ON-LINE command to the NI1010 cont- 
roller. The controller and driver will now be in a state no 
process commands and receive packets. 

One can modify NIDRIVER 's resource allocation strategy at 
run-time. To change strategy, one's program must supply (in 
the IC$_SETMODE! IO$_STARTOP QIO) the address of a guadword 
characteristics buffer in parameter PI and the size in tyres 
(always 16) of the characteristics buffer in P2. The first 
longwcrd (32-bit word) of the characteristics buffer is 
interpreted by NIDRIVER as follows: 

<3:0> the maximum number of receive buffers that 
NIDRIVER will pass to the controller with SUPPLY 
RECEIVE BUfFER commands (maximum of 16) . NIDRIVER 
will allocate 5 Onibus Adapter map registers for 
each as a result of this call. If this field is 
zero, NIDRIVER will use a default value of 4 and 
allocate 20 map registers for receive operations. 
(Five additional map registers are ALWAYS allo- 
cated for command DMA.) 

<3 1:4> RESERVED (must be zero) 

The second longwcrd of the characteristics buffer is inter- 
preted by NIDRIVER as follows: 

<0:0 = 0 (Default) Allocate a Buffered Data Path 

only when needed to process command operations 
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< 0:0 



that perform DMA. Deallocate the Buffered Data 
Path immediately after the command is finished. 

= 1 Permanently allocate a Buffered Data Path 
tc be used for command operations rhat perform 
DMA. 

<3 1;1> RESESVED (must he zero) 

lO^SE^O DE ! 1 0$ SHU TDOWN 

Issuing I03_SETM0DE ! IO$_SH UTDOWN causes HIDSIVER to shut 
down network operations. NIDRIVSR passes a RESET command to 
the controller. All outstanding receive (I0$_READL3LK) 
requests will finish with a status of SS$_ABORT. Any allo- 
cated Buffered Data Path will be deallocated. Any supplied 
characteristics buffer is ignored for this call. 

10 $ WRITE L3LK 

Issuing IO$_MRITELBIK causes the packet defined by QIO 
parameters PI and P2 to be transmitted onto the Ethernet. PI 
is the address of a WORD ALIGNED preformatted packet in 
memory. P2 is the length in bytes of the prefermatted 

packet. P2 must be greater than 0 and less than 1536 

(decimal) and even. The packet must follow the format 
described in Figure 4.2. The QIO request will remain 
outstanding until the packet is successfully transmitted 
onto the Ethernet (or an error occurs) . The IO$_WRITEPBLK 
function performs the same operation as the I0 $_writelblk 
function . 

10$ READLELK 

Issuing IC$_READLBLK causes the buffer defined by QIO param- 
eters PI and ?2 (address and size in bytes, respectively) to 
be used to hold the next received packet (or packet fragment 
if buffer-chaining takes place) . The buffer pointed to by P1 
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Figure 4.2 Transmit Packet Format. 

must be WCRD ALIGNED- The buffer size passed in P2 must be 
greater than 0, less than 1536 (decimal), and even. Packet 
placement into buffers is strictly FIFO; rhar is, the oldest 
outstanding buffer will receive the nexr incoming packet. 
The format of rhe received packet is shown in Figure 4.3. 
The QIO request will remain outstanding until a packet (or 
packet fragment) is accessed directly into the associated 
buffer. 
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Figure 4.3 Receive Paclcet Format. 

C CD trolle r S pecif ic Functions 

Because no existing VAX/VMS funcrion cedes correspond to 
NI1010 specific operations such as LOAD MULTICAST or SET 
FROMISCUCCS MODE, NIEEIVEE supports driver-spscif ic function 
codas. These codes are consrructed by passing the 

controller-specific command in the "function modifier" field 
of the I/C function value. The function value "code" field 
will be IC$_EEADL3LK, IO$_W RITELBLK, or IOS_SEEK, depending 
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command 



on whether the cont roller- specif ic 
memory access or not. For example, 
value specifies LOAD MULTICAST: 



performs direct 
the following function 



X20 ! < 0 52 3 6> = XAAO 



As a programming convenience, INTSRLAH provides symbolic 
names which can be used in the function argument of QIO 
service calls. File NIDEF.MAR can be used with MACRO 
programs and file NIDEF.FOR can be used with FORTRAN 
programs . 

One can use these definitions in a FORTRAN program by 
including the line: 

INCLUDE '_DRA0:[NPSSYS. INTERLAN ]NIDEF. FOR' 
in the FCETBAN source code. 



(2) . 1Z2 Comp l etion . One should always supply 

the address of a quadword I/O status Block (I0S3) IN THE 
"iosb" argument of the QIO request. On I/O completion, the 
lOSB will contain not only VAX/VMS status, but also cont- 
roller specific status as well. 

VAX/VMS status is returned in bits <15:0> of the first ICSB 
longwcrd. Bits <31:16> of the first IOSB longword do not 
contain any meaningful iraformation. If the returned VAX/vms 
status is SS$_NORHAL, Normal Successful Completion, bits 
<3:0> of the second IOSB longword will contain the Command 
Status Code from the ccntroller. Refer to the NI1010 Unibus 
Ethernet Communications Controller User Manual [Ref. 4] for 
a ccmplete description of the controller status codes. 
Appendix F describes which Command Status Codes can be 
expected for each QIO request. Bits <31:4> of the second 
IOSB longword do not contain meaningful information. 
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DESIGNING PROCEDDEE 



Since 

VAX/VMS 
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Reference 



NS2030 Device Driver 
mini-computer, the 
Corporation's Network 
Model menxioned in 



is inxended to be 
design is based on 
(DECNET) rather than 



Chapter II. Howeve 



used in 
Digital 
r he ISO 
, the 




Layer ISO DECNET 
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Data link 
Control 
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Physical 


Physical 



Figure 4.4 Happing between ISO Hodel and DECNET. 

layering concept is still used in DECNET. The approximate 
mapping between ISO Reference Model and DECNET is shown in 
Figure. 4.4. 

DECNET has only five layers. The physical layer, data 
link layer, transport layer, and network services layer 
correspond almost exactly to the lowest four ISO layers. 
However, the agreement breaks down at layer 5, since DECNET 
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has nc session layer, and the remaining layer, the applica- 
tion layer, is a mixture of rhe ISO presentation and appli- 
cation layers. 

Apparently, the NS2030 has covered both network and 
transport layers, thus, the only layer left to be developed 
is the application layer. 

• Ste^s in deve loping th e applica t io n layer 

With the suggestion from the NS2030 VAX/Vas Device 
Driver and Diagnostic Dser Manual [Ref. 5], VAX-FORTEAU 
programming language is chosen to be used in developing the 
application layer. Ihe other reason to use FORTRAN is 
because of the provided function argument of QIO service 
call in NIDEF. FOR fils in the Driver Routine. This makes it 
easier for the programmer to issue commands to the NI1010 
Onibus Ethernet Communications Controller Board. Steps in 
developing application layers are as follows: 

1) All available system service routines in VAX/VMS 
involving I/O operation are studied. Some of the very impor- 
tant routines which are used in developing the program are 
included in Appendix A. 

2) The first experiment is to check whether the 
program can really instruct the NI1010 Board what to do. 
This is done by writing a program that will send out a 
message to the NI1010 Board and direct the board to send the 
message tack to itself, i.e. , send the message from memory to 
the transmit buffer and send that same message back to the 
receive buffer of NI1010 Board. In order to do this, the 
NI1010 Board must be put in the INTERNAL LOOP BACK MODE. The 
detail of command descriptions available to be used with 
NI 1 0 1 0 Board can be found in NI1010A Unibus Ethernet 
Communications Ccntrcller User Manual [Ref. 4]. The program 
that is developed for this experiment is included in 
Appendix B. 
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3) The seccnd experiment is to do the same thing 
except that this time the message will be sent out to the 
transceiver and ontc the coax cable, but the Destination 
Address field contains the address of the board itself 
(02- 07- 0 1-0 C-07-7F) , thus this message will come back to the 
receive buffer again. This is called "EXTERNAL LOOP BACK 
MODE". 

4) After the first two experiments are completed 
successfully, the Deszination Address field is changed to 
that cf the NS3010 Beard implemented in the MDS system. We 
have two NS3010 Boards, one with address 02-07-0 1 -00-04 -OA 
and the ether with address 02-07-01-00-03-EA. 

5) The next step is to transfer a file. The same 
type of experiment which has been done in sending and 
receiving the message is used. The DOWNLOAD and UPLOAD 
procedure in the VAX/Vas are studied. All the FORTRAN 
statements used in file operation can bs found in VAX-11 
FORTRAN User’s Guide [Ref. 8]. 

2. Met hod to Ove rcome Fra me Seq u enc ing 

It has been mentioned earlier that the NI1010 Board 
does not have a capability to preserve the order of 

messages. Therefore the design of the application layer 
protocol should take this matter into consideration. 

The solution is that the convention of communicating 
between any two computer systems should be made such that 
both stations will be able to know each other’s status. The 
convention cf communicating has been established as follows; 

a) .The receiving station will send an acknowledge message 

every time a frame is received successfully. If an 

error should occur, no acknowledge message will be 

sent . 
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b) .Ih€ sending station should wait for the acknowledge 

message from the receiving station for a sufficient 
amcut of time (protocol in vax/VMS is set up for 5 
seconds), if there is no acknowledge message within 
this period of time it will retransmit the same frame 
again and wait for the acknowledge message. The same 
frame is transmitted for the total of 3 times ( 1 tran- 
smission and 2 retransmissions) before the transmit 
process will be aborted. 

c) .Tke convention used to differentiate whether the frame 

is carrying a message or a file is established by the 
use of the available Type field (2 bytes) of each 
frame. It has been set up as shown in Table I. 



TABLE I 

Type Field Protocol; (All in Hexadecimal) 



ettej 


BYTE2 


FUNCTION 






00 


00 


console message 




00 


FF 


acknowledge message 




OF 


00 


file 


transf er- 


first fri 


a me 


OF 


01 


file 


trans f er- 


interned 


frame 


OF 


OF 


file 


transf er- 


1 record 


file 


OF 


FF 


file 


tr ansf er- 


last fra 


me 
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IflPLEHENTATION 



The final software protocol (application layer protocol) 
whose source code is shown in Appendix C is now available in 
VAX/VMS for public use. This program is in the file 

ETHERNET .FOE. A user who wanrs to transfer files or messages 
between VAX/VMS and HDS systems can do so 
instructions given in VAX/VMS-HDS 



by following the 
Ethernet Local 



Communication Network User Manual included in Appendix C. 
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COSCLOSION 



Ihe principal goals of this thesis were met.. The devel- 
oped software protocol was tested with the actual transfer 
of messages and files between VAX-11/780 under VMS operating 
system and MDS System under CP/M-80 operating system. A 
fils as large as 43 Kbytes was transferred roughly in less 
than 42 seconds. 

At present, the program is available in VAX/VMS public 
user account under user name "INTERLAN*' with password **VMS”. 
The VAX/VMS-MDS Ethernet Local Communication Network User 
Manual is also available in the file ’’VMSMDS.DAT*'. The 
content in this file is exactly the same as the content in 
Appendix C in this thesis. Users who want to do the message 
or fils transfer can get the hard ccpy of this fils by 
simply legging into the VAX/VMS under user name and password 
mentiensd above and printing the file. Then the steps in the 
manual must be followed. 

The files in public user account are: 

ETH Jll . EOT ( so ur os code ) 

S THE E1. EXE (exec utab le code) 

This is a program to transfer a message in the INTERNAL 
LOCFEACK mode. 

SENDMSG. FOR 

SEND MSG. EXE 

This is a program to send a message, typed in from the 
terminal, from the VAX/VMS to the MDS System. It 
retransmits the same message 3 rimes with the interval 
of 5 seconds before the transmit process is aborted if 
there is no acknowledge signal from the receiving 
station. 
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GEIMSG. FOR 
GET MSG. EXE 

This program waits for the message intended for the 
VAX/VMS. It sends back the acknowledge signal to the 
sending station every time it receives a frame success- 
fully. The received message is displayed on the screen. 

DOWNLOAD. FOR 
DCWNLCAD.EXE 



This program is used to transfer a specified file from 
VAX/VMS to MDS System. It will wait for an acknowledge 
signal from the receiving station after every frame has 
been transmitted. The same frame will be transmitted 3 
times with the interval of 5 seconds before the 
transmit process is aborted, if there is no acknowledge 
signal from the receiving station. The file is trans- 
ferred by a record of 128 bytes so it would match the 
characteristics of CP/M records. 



UPLOAD. FOR 
UPLOAD. Jjffi 

It is a program used to receive the incoming file from 
the MDS System. It sends an acknowledge signal to the 
sending station for every successfully received frame. 
This program puis 7AX/VMS into a ready-to-receive-f ile 
mode until control-Y key is pressed. 

ETHER NET. FOR 
ETHER NET. 

This program is a combination of all the programs 
mentioned above. When execured, VAX/VMS will be ready 
to receive any message in the network which is intended 
for the VAX/VMS. The message will be interpreted 
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( 
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the 



whether it is a ordinary message, a request transf 
ring of file, or a request receiving of file. 

1) .If the message is an ordinary message, 

program prints that message on the screen, 
sends an acknowledge signal to the sending 
station, and is ready to receive ancrber 
message . 

2) .If the message is a request for transferring a 

file, the program sends back an acknowledge 
signal and transfers a specified file to the 
sending station until the whole file has been 
transferred successfully. The request for 
transferring a file message should include the 
filename and filetype, FN. FT, of the file which 
the requesting station wants to receive. If the 
public user account does not have the specified 
file, and error message will be sent to the 
requesting station to notify the user. 

3) .If the received message is a request for 

receiving a file, the program will send an 
acknowledge message together with instructions 
to the user of the requesting station to open a 
new file under the specified FN.FT, receive the 
incoming file until its all done, then send a 
message to the sending station that the whole 
file has been received successfully and then 
put VAX/VMS back to ready-to-receive-message 
mode. 

All of these files can be copied by any users by typing 
he following commands: 

JCcpy 

$From: _DRA1 :[ INT2RLAN ]FN. FT 
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.^1 
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% 



$Tc : 



NFN.NFT 



where FN.PT is the filename. filetype of the file tc be 
copied from, and NFN.NFT is the filename. filetype of the 
file to be copied to. The NFN.NFT will appear in the user's 
directory after the above sequence of commands have been 
executed. It is necessary that the file type of the new file 
should be xhe sane as the old file. 

Future research with VAX/VtIS Ethernet Software Prcxocol 
should ccncentrate on trying to make the MDS System terminal 
act like a virtual terminal of VAX/vas. There are system 
service routines available in VAX/VMS which support this 
capability. Anyone who is interested to do a further 
research in this field can get all xhe information about 
these routines from Mr. Albert Wong, VAX professional staff, 
in Rm. SP505. The modifications can be made without any 
changes in the present programs since this program is 
designed wixh a layering concepts of the network protocol. 

Another direction of research is to expand the network 
so that VAX/VMS can also communicate with other systems 
under different operating systems such as ISIS II or 
MCORTEX. 
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appendix a 

¥AX/Vas SYSTSM SERVICE SOUTINES 

The followings are the VAX/VMS System Service Routines 
which are used in developing the application layer protocol 
for rbe Ethernet Local Area Network. 

lASSIGN 

SASSIGN - ASSIGN I/O CHANNEL 

The Assign I/O Channel system service (1) provides a process 
with an I/O channel so that input/output operations can be 
performed or. a device, or (2) establishes a logical link 
with a remote node on a network. 

High-level Language Fermat 

SYSlASSIGN (devnam,chan,[ acraode ],[ mbxnam ]) 

devnam 

Address of character string descriptor pointer rc the 
device name string. The string may be either a physical 
device name or a logical name. If the device name 
contains a colon, the colon and -he characters that 
follow it are ignored. If the first character in the 
string is a underscore character (_) , the name is 
considered a physical device name. Orherwise, the name 
is considered a logical name and logical name transla- 
tion is performed until either a physical device name 
is feund or the system default number of translations 
has teen performed. 

If the device name contains a double colon (::) , the 
system assigns a channel to the first available network 



67 



dsvice (NET:) and performs an access function on the 
network. 



chan 



Address of a word to receive the assigned channel 
number . 

acmode 

Access mode to be associated with the channel. The most 
privileged access mode used is the access mode of the 
caller. I/O cperaticns on the channel can only be 
performed from equal and more privileged access modes. 

mbxna s 



Address of a character string descriptor pointing to 
the logical name string for the mailbox to be associ- 
ated with the device, if any. The mailbox receives 
status information from the device driver. 

An address of 0 implies no mailbox; this is the default 
value . 



Notes 

1) For details on how to use $ASSIGN in conjunction with 

network operations, see the DEC net-v A X User* s Guide 

CRef. 9]. 

2) Only the owner of a device can associate a mailbox 
with the device (the owner is the process that has allocated 
the device, either implicitly or explicitly) , and only one 
mailbox can be associated with a device at a time. If a 
mailbox is associated with a device, the device driver can 
send messages containing status information to the mailbox, 
as in the following cases: 
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a) .If the device is a terminal, a message indicates 
dial-up, hang-up, or the reception of unsolicited 
i r. pu t . 

c) .If the target is or. a network, the massage may 
indicate that the network is connected cr initi- 
ated, cr whether the line is down. 



For details on the message format and the information 
returned, see the VA X/VM S IZQ. Use r * s Guide (Hef- 7]. 

3) Channels remain assigned until they are explicitly 
deassigned with the Deassign I/O Channel ($DASSGN) system 
service, or, if they are user-mode channels, until the image 
that assigned the channel exits. 



4) The SASSIGN service establishes a path to device, but 
does not check whether the caller can actually perform 
input/cutput operations to the device. Privilege and protec- 
tion restrictions may be applied by the device drivers. For 
details cn hew the system controls access to devices. 



to 



see 



j 
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SQIOW - QUEUE I/O REQUEST AND WAIT FOR EVENT FLAG 



The Queue I/O Reguesttand Wait for Event Flag system service 
combines the $QIO and SWAITFR (Wait for Single Event Flag) 
system services. It can be used when program must wait for 
I/O completion. 



High-level Language Fermat 

SYSIQICW ([ ef n ] ,chan, f unc,[ iosb ],[ astadr ],[ astprm ] , 

CFnrCF2],Cp3],Cp4],[p5],Cp6]) 

ef n 



Number of the event flag that is to be set at request 
completion. If net specified, it defaults to 0. 

chan 



Number of the I/O channel assigned to the device to 
which the request is directed. 

f unc 

Function code and modifier bits that specify the opera- 
tion to be performed. The code is expressed symboli- 
cally. 

iosb 



Address of guadwerd I/O status block nhat is to receive 
final completion status. 



astadr 



Address of the entry mask of an AST service routine to 
be executed when the I/O completes. If specified, the 
AST routine executes at the access mode from which the 
SQIO service was requested. 
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ast pr HI 



AST parameter to be passed to the AST completion 
routine. 

pi to p6 

Optional device- and function-specific I/O request 
parameters. 

The first parameter may be specified as pi or piv, 
depending cn whether rhe function code requires an 
address or a value, respectively. If the keyword is not 
used, pi is the default; that is, the argument is 
considered an address. 

F2 through Pn are always interpreted as values. 

Notes 

1) The specified event flag is set if the service termi- 
nates without queuing an I/O request. 

2) The I/O status block has the following format: 



31 16 15 



BYTE COUNT 


STATUS 


DEVICE- AND FUNCTION- 


DEPENDENT INFORMATION 



a) .status - completion status of the I/O request. 

h).byte count - Number of byte actually transferred. 
Note that for some devices this contains only the 
Icw-crder word of the count. 

c). device- and function-dependent information - Varies 
according to device and operation being performed. 
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The informaticn returned for each device and func- 
tion code is documented in the VAX/VMS I/O User’s 
Guide [Ref. 7 ]. 

3) Many services return character string data and write 
the length of the data returned in a word provided by the 
caller. Function codes for the $QIOW system service (and 
the LENGTH argument of the SOUTPUT sysrem service) require 
length specif ications in longwords (32-bit word) . If 
lengths returned by ether services are to be used as input 
parameters for SQIOW requests, a long word should be reserved 
to ensure that no error occurs when $QIOW reads the length. 

4) For informaticn on performing input and output opera- 
tions on a network, see the DECnet-VAX User’s Guide 
[Bef. 9]. 
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$EINTIME 



SBINTIME _ CONVERT ASCII STRING TO BINARY TIME 

The Convert ASSCII String to Binary Time system service 
converts an ASCII string to an absolute or delta time value 
in the system 64-bit time format suitable for inpux to the 
Set Timer ($SETIMR) or Schedule Walceup (SSCHDWK) system 
services. 



High-level Language Fermat 

SYSlEINTIM (timhuf ,timadr) 
timbuf 



Address of a character string descriptor pointing to 
the buffer containing the absolute or delta time to be 
converted. The required formats of the ASCII strings 
are described in the Notes, below. 



timadr 



Address of a quadword that is to receive the converted 
time in 64-bit format. 

Notes 

1) The SBINTIM service executes at the access mode of 
the caller and does not check whether address arguments are 
accessible before it executes. Therefore, an access viola- 
tion causes an exception condition if the input buffer or 
buffer descriptor cannot be read or the output buffer cannot 
be written. 

2) This service does not check the length of the argu- 
ment list, and therefore cannot return the SS$_INSFARG 
(insufficient arguments) error status code. If the service 
does not receive enough arguments (for example, if one omits 
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required ccnunas iu the call) , one might not get the desired 
result. 

3) The required ASCII input strings have the formar: 

Absoluts Time; dd-mmm-yyyy hh:mm:ss.cc 



Delta Time: ddd hh:mm;ss.cc 



Fiel d 

dd 

mmin 



iiih 

hh 

mm 

m 

ss 

cc 



le ngt h (byte s) Co ntents 



2 

1 

3 



1 

4 

n 

2 

1 

2 

1 

2 

1 

2 



day of month 
hy phen 
mo nth 



dddd 

Note that 



4 

mont h 



hy phen 
year 
blank 
ho ur 
colon 
minute 
CO Ion 
se cond 
pe riod 

Hundredths of 
se cond 



Ra nge of values 
1 - 31 

Reguired syntax 
JAH, ?E3, 3AS, APR, 
MAY, JUN, JUI, AUG, 
SEP, OCT, NOV, DEC 
Required syntax 
1858 - 9999 
Required syntax 
00 - 23 

Required syntax 
00 - 59 

Required syntax 
00 - 59 

Required syntax 
00 - 99 



number of days 000 - 9999 
24 -hour units) 



In 



(in 24 -hour units) 

abbreviations must be upper case, 
contrast with previous versions of vax/VMS, the hundredths 
of second field now represents a true fraction. For example, 
the string .1 represents ten hundredths of a second (one 
tenth of a second) ; the string .01 represents one hundredth 
of a second. Note also chat a third digit can be added to 
the hundredths of second field; this thousandths of second 
digit is used to round the hundredths of second value. 
Digits beyond the thousandths of second digirs are ignored. 

4) The following syntax rules apply to specifying the 
ASCII input string; 



a) . Any of the date and time fields can be omitted. 



Per absolute time values, the SBINTIM service 
supplies the current system date and time fer nonspe- 
cified fields. Trailing fields can be truncated. If 
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leading fields are omitted, the punctuation (hyphens. 



blanks, colons, periods) musr be specified. For 
example, the following string results in an absolute 
time of 12:00 cn the currenr day. 



For delta time values, the $3INTIM service defaults 
ncnspecified hcurs, minutes, and seconds fields to 0. 
Trailing fields can be truncated. If leading fields 
are emitted from the time value, the punctuation 
(blanks, colons, periods) must be specified. If the 
number of days in the delta time is 0, a 0 must be 
specified. For example, the following string results 
in a delta time of 10 seconds. 



Note the space between the 0 in the day field and the 
two colons. 

b) . For both absolute and delta time values, there can 
be any number of leading blanks, and any number of 
blanks between fields normally delimited by blanks. 
However, there can be no embedded blanks within 
either the date or time fields. 

The following examples illustrate legal input strings to the 
$3INTIM system service, and the time represented by the 
output from the IBINTIM system service (translated through 
the Convert Binary Time to ASCII String (SASCTI.T) system 
service). Assume that the current date is IU-jUN-1983 
04: 15:28.00. 

ic SBINTIM IASCT^ ou tput string 



12 : 00 : 00.00 



0 : : 1 0 



50 



14-JUN-1983 04:50:28.00 



--1984 0:0:0. 0 
9-NOV-1982 12:32: 1. 1 161 



14-JUN-1984 00:00:00.00 
9-NOV-1982 12:32:01.12 



75 



22-AER-1983 16;35;0.0 



22-AP8-1983 16:35:00.00 



0 : : , 1 
0 : : . 06 
5 3: 18: 32.068 
20 12 : 

0 5 



0 00 :00 : 00 . 10 
0 00:00:00.06 
5 03:18:32.07 
20 12 : 00 : 00.00 
0 05:00:00.00 
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SSETIKE 



SSETIMR - SET TIMER 

The Set liner system service allows a process to schedule 
the setting of an event flag and/or the queuing of an AST at 
some future time. The time of the event can be specified as 
a absolute time or as a delta time. 

When the service is invoked, the event flag is cleared 
(event flag 0, if none is specified). 

High-level Language Fermat 

SY SSSETIMR ( [ef n j ,daytim ,[astadr] ,[reqidt]) 

efn 

Event flag number of the event flag to set when the 
time interval expires. If not specified, it defaults to 

0 . 

dayt im 

Address of the guadword expiration time. A positive 
time value indicates an absolute time at which the 
timer is to expire. A negative time value indicates an 
offset (delta time) from the currant time. 

asta dr 

Address of the entry mask of a AST service routine to 
be called when the time interval expires. If not speci- 
fied, it defaults to 0, indicating no AST is to be 
queued . 

reqidt 

Number indicating a request identification. If not 
specified, it defaults to 0. A unique request 
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( 

i 

I 

I 

( 



I 



id 

re 

re 

la 

ro 

th 

Notes 

1 ) 

the rsq 

2 ) 

passed, 

within 

3 ) 

system 

guadwcr 

service 



entification can be specified in each set 
quests, or the same identification can be giv 
lated timer requests. The identification can be 
ter to cancel the timer reguest(s). If an AST se 
utine is specified, the identification is pass 
e AST parameter. 

The access mcde of the caller is the access me 
uest and cf the AST. 

If a specified absolute time value has al 
the timer expires at the next clock cycle (tha 
10 milliseconds). 

The Convert ASCII String to Binary Time (SEI 
service converts a specified ASCII string to 
d time format required as input to the SS 



*imer 
sn to 
used 
rvice 
ed as 



de of 
ready 

V- -S ^ 

NTI«) 
the 
ET IMR 
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SWAITFR 



SWAITFR - WAIT FOR SINGLE EVENT FLAG 



The Wait for Single Event Flag system service tests a 
specific event flag and returns immediately if the flag is 
set. Otherwise, the process is placed in a wair state until 
the event flag is set. 

High-level Language Fermat 

SYSJWAITFR (efn) 



efn 



Number of the event flag for which to wait. 



Notes 



The wait state caused by this service can be interrupted 
by an asynchronous system trap (AST) if (1) the access mode 
at which the AST executes is more privileged than or equal 
in privilege to the access mode from which the wait was 
issued and (2) the process is enabled for ASTs at that 
access mode. 

When the AST service routine completes execution, the system 
repeats the SWAITFR request. If the event flag has been set, 
the process resumes execution. 
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SCANTIM 



SCANTIM - CANCEL TIMES 

The Cancel Timer Request system service , cancels all or a 
selected subset cf the Set Timer requests previously issued 
by the current image executing in a process. Cancellation is 
based cn the request identification specified in the Set 
Timer (SSETIMR) system service. If more than one timer 
request aas given to the same request identification, they 
are all canceled. 

High-level Language Fermat 

SYSSCANTIH ([reqidt] ,[acmode]) 

reqidt 

Request identification of the timer request (s) to be 
canceled. A value of 0 {the default) indicates that all 
timer requests are to be canceled. 

acmode 

Access mode of the raquest(s) to be canceled. The mest 
privileged access mode used is the access mode of the 
caller. Only those timer requests issued from an 

access mode equal to or less privileged than the resul- 
tant access mode are canceled. 



Notes 



Outstanding timer requests are automatically canceled at 
image exit. 
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APPENDIX B 



SOORCE CODE 



FOR EXPERIMENTS 



All the source cede in 
the sxep-by-step design of 
Each cf the programs incl 
function when it is execute 



this appendix was developed 
the Ethernax Software Prot 
udes a brief explanaxion o 

d. 



from 
cccl, 
f the 
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Pt?OGRaM etheri 



C 

c 



c 



c 

c 



c 



c 



c 



TR4NSFER MESSAGE/IMTERMi^L LOOPRAC'<. 



cHaracter*?6 

intsaer*? 

intsaer*^ 

include 

include 

byte 



text /'This nessane »^;il1 oe sent.*/ 
i oso ( 2 ) 

nichan, svsTniow, sys^assinn 
'e/iraO: fnossys. inter) anl . for* 

' C^iodef ) ’ 

Toac !<■ e t ( 1 56 ) f P oac e t ( 1 ^ 6 ) 



Assidn destination address: 
Toacl<et(i) = '02'x 
Toacket(2)='07'x 
Toackst (3)=*01 ' x 
Toacket ('4) = '00'x 
Toaci^et (S) = ' 0 7 ' x 
t oac ket(6) = '7P'x 



Tyoe assiannent: 000 0 = tiso, etc. 

toacket (7)=’00'x 
Toacket (8 ) = ’ 00 ' x 



®ut data into transmit oacket: 
do 1 = 1 » 26 

Toacket()) = ichar(text(i :i )) 
j = i M 

end do 
do 1=35,156 

toackef(l)='00'x 

end do 



Assidn a channel to dlAO: 

i stat=sysSassian( 'NIAO' ,nichan, , ) 
if(.not.istat) call libSstoo(%va)(istat)) 
tyoe A i s t a t = ' , i s t a t 

Start uo and oo on line: 

israt= sysSdiow(»'':va1TnichanT, 

1 %val(ioS<-setTioie .or. iofTestartuo), 

2. ioso/», 

if(.not.istat) call lib5stoo(%val(istat)) 
ifCiosb(l).ne.l) call lib^stooT%val<’ioso(l))) 
tyoe S istat = ',istat,' S iosb('l) = ',iosb(l) 

Internal loooback: 

istat = sysSoioi^(,*<val (nichan), 

1 ’/valCioh^-siln), 

2 ioso, ,,,,,,,) 
if(.not.istar) call lib5stoo{%val(ista*’)) 
if(iosb(l).ne.l) call lioSstoo(%wal(iosn(l)l) 
tyoe X,' I istat=',istat,' I icso(l)=',ioso(l) 



^rofriscuous: 

i s t a t = s V s B a i o w ( , % v a 1 ( n i chan) , 

1 ’:val(ioe<-sDrT>), 

2 ioso,,,,,,,,) 

if(.not.istar) call libSstoD(%val(istat)) 
if(ioso(i).ne.l) call lioSstoo(%val(ioso(l))) 
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c 



c 



c 



c 



Receive on error; 

istat = sys?aio«^(f’<val fnichan), 

1 %va1(io«-^'SroeTi), 

if(.not.istat) call Hbfstoo(%va1fistat)) 
if(iosbO).ne.l) call libistooC^valCiosbCl))) 

T ransfii i C oac ket ; 

istat=sys?aiow(,%val (nichan)» 

1 *4val(io'*«-writelolk)# 

2 i osb f . r 

3 %ref (Tcacker ) ,*/iva1 ( 1 36) , , , , ) 
if(.not.istaf) call lib3st-oo(%val(isfat)) 
if(iosb^l).ne.l) call lib'SstooClivalCiosofl))) 
tyoe * , ' T istat = *»istat»' T iosb(l) = 'riosbn) 
tyce *» Toacket 



Load i:ranS''nit- data arc) send: 

isfat=sys6a'iow(/%val (nicnan), 

1 %val(io«-^ltd)/ 

2 i OSD » f f 

3 %re'f(Toacket)/%valfl3t))/,»,) 
i^C.not* istat) call lio^stooCZyalCistat)) 
tyoe */' ^lessaqe is beina transmitted....' 

Receive same oacket: 

tyoe start receivino' 

istat=svs3aio>^(fZval (nicHan), 

1 ZvalHoSt-readlblk), 

2 i 0 sb f / f 

3 %ref(RDacket)»%val(l^o),,,,) 

tvoe * , ' iosb(2)='fiosoC?) 

if{. not. istat) call libSstoo(Zval(istat)) 
if(iosb(i).ne.l) call lib‘^stoo(%val(iosn(l))) 
tyoe R istat='fistat/' R iosb (!)='» iosb(l) 

t yoe *»Roacket 
i = 19 

do while (Roacket(i).ne.icharf'.')) 
tyoe * f c h a r ( R o ac k e t ( i ) ) 
i = i t 1 

end do 
call exit 
end 
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5 



ooono 



DR0GR4V' SEND^'lSG 



ACTUAL SSNDIMG OF 'MESSAGE. 
.-jAIT FOR ACKU0-*:LEDGE . 

IF NOT ACKMO-JLEOGE IM 5 SEC, 
IF NOT ACKNO^vLEOGE IN 10 SEC, 



RET.RANS'-M T . 
abort TRANS'^'ISGinN 



e X t e r na 1 
inteaer*2 
inteaer*0 
i n t ?oe r * tl 
i nt aae***^ 
include 
include 
D V t e 
b V t e 



t ^ r 



aoo r t 

i o s o ( 2 ) , a d d r 

nicban, avsf. ainw, sysSa'^ainn 
s/sSbintiTi, sysBaetinn, svsBwai 
systiTie( 2 ),tiTie( 2 ) 

'<-draO: [nnssys. interl an) nidef. for' 

• (Tiodef ) ' 
oad( 100 ) 

Toac'ce*' ( 1 3o) , fext C 1 ? 0 ) ,-'oac<ef ( ISO) 



C Ass i an a c^anne’ to 'I TAG: 

10 istat=sys 3 assign!' ''!lA0’,nic ban,,) 

if(.not.istat) call Iib 6 stoo(’/:yal(ist 3 r)) 



S*’art UD and ao on M'ne: 

istat=sysSgiow(,%val (nicnan), 

1 y a 1 ( i o s e t node 

2 ioso,,,,,,,,) 
if(.not.istat) call linTstooCXvaHistat)) 
if(iosb(l).ne.l) call libBstoDC%val!ioso(l))) 



or. io^T. ♦■start ud) 



c 


Assign destination addre 
Toacket('i) = *02’x 
^oac<et(2)=*07*x 
Toacket (3)=*01*x 
Toacket C 4 ) = * 00 ’ x 


s s : 




c 


Interact witd user! 






20 


type * f ’ Select '^et 


Address of 


Oesi’ination:* 




tyoe ^ ’ ^IDS Systen 


00-04-0A ; 


tyoe” 1 




tyoe *9 * “^DS System 

read(5f 1 1 )addr 


00-03-EA : 


tyoe" 2" • 


1 1 


1 0 rna t f a 1 ) 

if (addr.ea.*!*) tne»^ 







ToacVet (5)= 
ToacWet ( 6 )= 
else if ( addr . ea . '2 
ToacWet (5) = 
ToacWet ( 6 )= 



04 • X 
0 A • X 

) t 3 an 

05 • X 
E ^ ' X 



22 

C 



else 

goto 20 

end i f 

tyoe *,'Inout nessaae(l2‘' 
read(5,22)text 
f ornat ( 1 2 da 1 ) 



char "'ax)end wi' 



Assign tyce ^ield: 

Toac ket ( 7 ) = ' 00 ' x 
Toacket(B)='00'x 

®ut data into transmit oac<et: 

i="*. 

do 1=1,23 

Toacket ( j )=text ( i ) 



don * r c a r ^ 



it is a nessane 
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I 



end do 



i = jn 



C Transmit oacket: 

30 istat=sysBaiow(f*4val(nicHan)f 

1 % V a 1 f i o 3 ^ w r 1 t e ] ^ 1 ^ 

2 i o s b f # f 

3 %reffToacker)f’^vaM13b),/^r) 

i f ( i o s b ( 1 ) . I t . 0 ) cal) I i b 3 s t o o f ’/« v a I i o s o ( 1) ) ) 
if(iosb(^?).ne.O) call )ib3stoo(%val(iosbf2))) 
tyoe ’^essaoe is beinq t rans^ i 1 1 ed * 

C Load transmit data and send: 

istat=svs5Qiowf/’>:;val (nicdan), 

1 % V a 1 f i o 1 t os ) f 

2 \ O S'O f f f f f f f r ) 

i f(iosbCl).l^.O) call 1 ioBstooC^vai (i^snC] ))) 
if(iosb(?),ne.O) call libfstoor^^valfiosbf?))) 

C A/ait for 10 seconds and abort: 

call sys3bintimf*0 ::10.0*^tine) 
cal 1 sysSsetimrCrtime/aDort*,) 

C /is } t for 5 second an ci retransmit: 

call sys3bintimf*0 ::5,0*^svstime) I retransmit 
call s V s 3se t i m r ( 1 / s y s t i me f f ) ! aft^r S sec. 

C Receive acknowledoe: 

istat=svs3qiow(fXval (nichan)^ 

1 %val(ioS^read]n]<)/ 

2 i osb f ^ f 

3 %ref (Roacker ) . % v a 1 ( I 5 0 ) , , , , ) 
ifCiosb(l).lt.O) call 1 ib3stoo(*^val (iosofll)) 
if(iosb(?).ne.O) call )ib3stoD(';valfioso(2))) 

C Check the second tyoe field if = Hex: 
if (PoacketflB).eo.*FF*x) then 
i = 19 

do while (Roacket(i).ne.ichar(*'*)) 
i = i t I 

end do 

write(6/33)(^oacket( j)r i=19fi-l) 

33 format)'* *f<i>al) 

call sysBcantimf , ) [ cancel timer 

Roacket fl^) = *00’x 
aoto 20 

end if 

call svs3waitfr(l) 

aoto 30 

end 

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC 
SUBROJTpJE APORT 
wri t ( h f 222 ) 

222 formate* Abort Transmission*) 

call e ^ i t 
end 
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I 



oooo 



program getmsg 



C 

C 



C 

10 



ACTUAL RECEIVINJG OF 'MESSAGE. 

SEMO back ledge MSG. (2nd fvoe ^i®ld-FF n<ay)^ 

IF received bad ‘^RA^iE, 00 ^JOTHING BUT vVAIT TO ‘<ECEI/ 



character^25 
inteoer*2 
i nt^aer^^ 
include 
include 
b V t e 

b V t e 
bv t e 



nsalM* Receiv/e '=;uccessfu1]^.'*/ 

1 o s o ( 2 ) 

nicnan/ svsBaio--^/ svsSn^sinn 
*^nra0: [nos3ys.inte'"l3nlni :ef*^nr 

* ( Tiodef ) * 
o a d ( 1 0 0) 

RoacKet ( ISO ) p roac<et ^ 1 3n) 
d^i lnan(<4 0)/S^i ln3Ti('J0) 



Ass 1 an a channel to ^ilAO: 

istat-sys^assian( **\IIA0' / oicnan / # ) 
if(.not.i3i’at) tvoe ^ t * ^ssi:jn er'^orl' 



Start JO and ao on line: 

istat= sys5aiow(/%val(nicOan)/ 

1 ^val(ioB<-setnode .or. ioFn<-startuo)# 

2 iosb##//////) 

^f(.^ot•ista^) ^voe Istat start uo erro^l' 

if(iosb(l)*1t.0) tyoe ^9 * 3»*art: uo errorl* 



Receive inconi no nessaaer 

tvoe Ready to receive * 

istat=sys5qiow(f%va1 (nichan)/ 

1 %val(ioB^reaa1r'l<), 



? 


i 0 S 0 » / / 






3 


V 


r e f ( Roac 


» t ) , ’x: V 0 1 


n?0) , 


if(. not. istat) th 


en 






tyoe 


*, ' 


Send nsg 


istat receive 


goto 


1 0 








end if 

i f f i o s b ( 1 ) . 1 t 


.0) 

' 


then 






t voe 


Send 71 s o 


V AX /VMS 


r e c e i v 


ao t 0 


10 








end if 

i f(iosb(2).ea 


. 1 ) 


t ^ en 






tvoe 


' 


Send TiSQ 


r “=C *? i V ? 


block 


ao t o 


1 0 








end, i f 

ifHoso(2).eq 


.2) 

* , ' 


then 






tvoe 


Receive 


block 3 1 i 


on 7>en t 


ao t 0 


1 0 








end i f 

i f( ioso(2) .ea 


. '4 ) 


then 






tvoe 


* , ' 


Send s a 


i s s i n o 


r e c ^ i V 


goto 


i 0 








end if 

i f(iosb{2).ea 


.17) 
*, ’ 


t n e n 






tvoe 


S e n r;; 71 S 0 


0 V ^ r o (2 e 


i V e d 0 



goto 10 

eno if 
i =1Q 

do ^hile (Roacket(i).ne.ic^ar(*'*)) 
i = i ^ 1 



end do 

writef6/ll)(Roac'<9t(j)/j = ld^i-l) 
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11 ^or’^atC* */<i>al) 

tyoe Received successfully.* 

C -^ssiqn destination address: 

Toacketd ) = ’0R’x 
Toacket(2)=*07*x 
Toack9f(3) = *0l d 
Toackef dJ)=Roacket ( Id) 

Toac<et(5)=Rnacket ( IS) 

Toacket (6)=^^oacket ( 16) 

C Assign tyoe field: 

Toacket(7) = *00’x 1 indicate t-hat it is a ressaae 

Toacket(8)-*FF*x i acknowledoe si anal 

C ^ut data into transnit packet: 

J 

do i - 1 / 3 

T o a c k e t ( i ) = i c n a r ( n s ^ ‘4 1 i : i ) ) 

1 = j H 

end do 

C Transnit packet: 

istat=svs5qiow(/%val Cnichan), 

1 %val(ioi^writelnlk)f 

2 i oso / / f 

3 %ref(Toacket)^%val(13b)//ff) 

if(iosbfl).lt-.O) call lio5ston(Xvairioso(l))) 
type Acknowledqe is being ^ransnitted. 

C Load transmit data and send: 

istat=sys-Saiow(/%val (nicHan)f 
1 %va ir i 1 t ds ) / 

if(iosb(l).lt*0) type ^ f * Fther xn^it error’* 
if(iosb(2).ne*0) tvoe Controller xnit e^'rori* 

goto 10 
end 
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P'ROGRA'^ UPLOAD 



C 

C 

C 

C 

C 

C 

C 



C 



C 



c 



ACTUAL receiving of FILE. 

DISCARD last c-pA'^E. 

CHECK FOR 1 RECOPO PILE. 

SEND BACK ACKNOWLEDGE '^SG.(2nd tyoe fieli^PP hex). 

IF RECEIVE BAD FRAME, DO NOTHING PUT A [ T TO DECEIVE 

same frame again. 



character*?'-) 

i n t eqe r * ? 

i n t eqe r * 4 

include 

include 

byte 

byre 

byte 



nsol/' Received successfully.'’/ 
i osp ( ? ) , done 

nichan, sys5oio-x, svsBassiqn 
'edraO: fnossys.interlanlnidef.for' 
' (Si odef ) ' 

oad ( 1 00 ) 

Poacket ( ISO) , if i 1 naTi(40) 

Toacket ( 1 56) 



Assiqn a channel to ''lAO: 

istat=sysSassiqn( '^IIAO* , nichan, , ) 
if(.not.istat) call libSsroof^i^vaMistat)) 



Start uo and no on line: 

istat= sysBqiow(,’(val (nichan), 

1 .^vaHioS^-setnode .or. ioSmestartuo), 

2 iosb, ,,,,,,,) 

if(.not.istat) call lib5srop(%va1(istat)) 
if(iosbM).lt.O) call libSston(%val(ioso(l))) 
if(iosb(2).ne.O) tyoe *, 'Controller Start uo error' 

Initialise flaq: 
done=0 



C Interact with user: 

2 tyoe *,' Destination filename?' 

read(5,5?)In,dfi Inan 
dfi1nam(lo-tl)=0 
52 for-nat(q,'-J0al) 

ooen(na'Tie=dfi loan, uni t=2,orqani zat ion='seouent i a1 ' , 

1 tyoe='new',carriaqecontrol='list',iostat=ios,err=7) 

00 t o 10 

C7 -tyoe *,' Ooen file fail! T~v aqain' 

7 call libSston(%val(ios)l 

qot 0 2 

C Receivefile: 

10 tyoe °eady to receive....' 

20 istat=svsSqiow(,%val(nichan), 

1 ’4val(io5*-r=»adlblk), 

2 i o s p , , , 

3 7,ref(Roack‘:»t),%val(lS0),,,,) 
if(.not.istat) call libSstoo(%val(istat)) 
if(iosb(i).lt.0) call iibSstop(’4val(ioso(l))) 

i f ( i o SP ( 2 ) . ne . 0 ) tvne *,' Controller Rfac“ive error?' 
if (Roacket(lH).eo.'OF’x) then 1 a 1 record file 
wri te(2,'o50) (Roacket ( j ) , i = lR, 146) 
d o n e = 1 
no t o 4 0 

end if 

if (Roacket(lS).eQ.'FF'x) then 
done= 1 
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i 



ao f o 0 

end if 

write(?/S50) (F?o3ci<et( ] ) f ] ^ l'^6) 

550 fomat(l^?^al) 

C Assiqn destination address! 

^0 ToacketM)-*02*x 

Toac Wet (2)=: ^37 * x 
Toacket(3)==*0l *x 
Toacket (^)=:RDacket ( 1^) 

Toacket (5)=^WoackPt ( 15) 

Toacket (6)-RDacket ( lo) 



Ass ion tyoe field! 
Toacket(7)r*00*x 
Toacket (0)=*FP • x 



indicate that it i 
ackno'wledqe sianal 



s sao^ 



30 



Put data info transmit racket: 
do 1 - 1 ^ 

Toacke^'( i ) = ichar(Tsql ( i :i )) 
j = i ^ I 

end do 

Transmit oac ke t ! 

istat=sys3aiow(/%val (nichan)/ 

1 %val(io3^write1o1k), 

2 i o s b f / f 

3 %ref(Toacket)r%val(l3o)f///) 
ifCiosbCl),lr.O) call libSstoo(%va1(ioso(l))) 
tyoe ^ f * Acicnowledqe is neinq transmitted.... 



Load transmit data and send: 

istat=sysBaio^(/*^val (nicdcan) , 

1 % va H 1 ot-e I t (is 1 , 

2 iosb#///r//f) 

ifCiosb(l).lt.O) tyoe Ether xmit 

i f ( i osb ( 2 ) . ne . 0 ) tyoe Controller 

if (done.eq.l) Qoto 30 

qoto 20 

closefuni t=2) 



error! 
xmit error 



type 

cal) 

end 



Receive comoletea 



exit 
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oooo 



PROG^^AM DOi\-'JLOAD 



actual tramsfe^^ ftle/iuteractt;e. 

PETPAUSMIT same FPA^iE IF NO ACK Nf3i^LF0GE IM 5 S^C. 
abort transmission [F not receive AC-<^J0:.^ILE0GE pi i) SEC. 



C 



externa) 
inteaer*? 
inteaer*ii 
i nteqer*^ 
i nc 1 uie 
include 
byte 
byte 
b V t e 



abort 

lOso(R)/ addr/ county none 
nicranf sysvoio/^^ sys-assinn 
i'ine(R)#svstiTie(E)/SecrRj 
*^braO; [nossvs. inter) 3n)niO'=»’.for'* 
* ( 5 1 ode t ) * 
o a d ( 1 0 0) 

Toacket (I ^6) fsM )nan(40) 

Roacke*' ( ISO) 



Assign a channel to i I A 0 : 

istat=sys5a33ion(*^l[A0* ^nic’^an^ ^ ) 
if(.not.ist-at) cal) )ioSstoo(%va)(ista^)) 



C Start UD and oo on line: 

istatz svs5niow(/’^va)(nicnan)# 

I ’4va)(ioB<“SetTiod‘=» .or. ioi>nn^-s^art'jo)r 

if(.not.istat) cal) libSstoof’^vairistat)) 
if(iosb(l).)t.O) cal 1 ) inJ'StooC^val (ioso(l))) 

i f ( 1 o sb ( 2 ) . ne . 0 ) tvoe ^ * Con t r o 1 1 e r Start uo error* 



C Assign destination ai dress: 

Toacket(l)=*02*x 
Toacket(2)=*07*x 
Toacket (3)=*01 *x 
ToacketC^-l) = *0 0*x 

C Interact with user: 

10 tyoe Select Net Address ot Destination:* 

tyoe Syste^i OO-OO-OA : tvoe’*!'** 

tyoe MOvS Systeri 00-03*EA : tvoe’*2’** 

read ( 0 / 1 1 ) addr 

11 format(al) 

if (addr.ea.*!*) then 

Toacket (5)=*0A*x 
Toacket (b)-*0A* y 
else if (adar.eo.*2*) tnen 
Toacket(S)=*03*x 
Toacket (h)=*EA*x 

else 

goto 10 

end if 

C Assian ^yoe field: 

Toacket (7 ) = ' OF * x 

Toacket(3) = *0 0’x i first ff'ane r<^cin(^)=0 0 nex 

C Initialiee flag: 

done - 0 



C Interact with user: 

20 tyoe Source filename?* 

reaO(5^?2)lnfSfi Inan 
sTi )nafn(ln-tl)=0 
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22 



9 



C 

30 



53 

ao 



c 



c 

c 



r 



c 



c 



fomat (qr^Oal ) 

ooenCname-sH InaT) fUnit = lfOrqanizetion=*SP^ 3 uenti;=^) * 
1 rtyoe=*oM*#C 9 rriaQecontrol = *Hst'/arr="'^) 

Goto 50 

tyoe * Mo such file! Trv aaain* 

Goto 20 

Transnm’f oacket: 
count =0 

reacl(1 / 53# iostat-ios^end^lOOferr-lOl ) 

1 (Toackec(j)#j=^^ 136 ) 

f omat ( 1 28a 1 ) 

istat=sys5oiow(f%val (nichan), 

1 %va1(ioS^writelol'<lr 

2 iosDfff 

3 %ref(foacket)f%val(l3o)#,,,) 

if(iosb(l).lt.O) call 1ib3stoo(%val(iosn(l))) 
i f ( 1 osb ( 2 ) . ne . 0 ) tvoe ^ ^ * C on t ^o 1 1 a T^ans'^it error' 
tvoe ^iie is oeinq transnitt^i ’ 



Load transmit iata and send file: 
i3ta^=sys3aiow(f*^val (nichan)# 

1 %va 1 (io^<- 1 tds)# 

if(iosb(l),1t.0) tyoe * ^ * System x^if erporl* 
if(iosb(2).ne*0) tyoe Controller <mit errorl* 

A’ ait for 2 0 seconds and abort: 

call svs3ointim(*0 ::20,0*fSec) 
cal 1 sys5setimr(rseCf3bortf ) 

dait for 10 seconds and abort: 

call sys$ointim(*0 ::l0.0*ftime) 
cal 1 sys3setimr(2ftimeff) 

>/ait for 5 second and retransmit: 

call sys'SbintimC’O ::5.0*fSystime) 1 'vait for 

call sysSsetimr(lfSvstime#f) 1 acknowledoe 5 sec. 



Receive ac^nowledoe: 

i3tat = svs5aio/^(f'<val (nichan)^ 

1 %val(io3<-readlblk), 

2 i oso f # f 

3 %ref(Roacket)/%y/al(lS0),fff) 



Check the second tyoe field if = 

if (Roacket(lo).eG.*FF*x) then 
call sys3cantim(f) 
Roacket ( I S) = » 00 * x 
i f ( done . eo . I ) qoto SO 
Toacket (8) = *01 * x 
Goto 30 

end if 

if (count. ne. 2) then 

call svsS^ai^fr(l) 
COunt=count'tl 
qoto d 0 

enq if 

call svsSwaitfr(2) 

call exit 

call lib3stoo(%val(ios)) 



hex! 

1 cance 1 timers. 
I clear flag 

i middle f r a m e 



9 1 



lOl 



I 



C Assicin value to end Tessaae: 

100 do i =9 / 1 5o 

To 3C 9 1 ( i ) =* 52 ’ X 1 blank c^iar 

end do 

Toac lot ( 8 ) = * PF ' X 1 lasttraTie 

done = 1 

goto JO 

50 tyoe */' Transniit co'^oleted' 

close(unit=l) 
goto 10 
end 



cccccccccccccccccccccccccccrcccccccccccccccccccccccccccccccccccccc 

SUB90UTT\'E AnQOT 
wri te(^»222) 

222 fonat(' inert T r aissi i s 3 i on ' ) 

call exit 
end 
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AElliiDix c 

ETHERNET SOFTHiRE PROTOCOL SOORCE CODE 



This is the actual source code which is developed to 
meet the principal gcal of this thesis. This program is also 
available in VAX/VMS public user account under fils name 
•'ETHE5NET.FCE''. 
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ooooooo 



program ETHERNET 



To 



ACTUAL RECETVING OF message. 

SEND 3AC< acknowledge MSG,(2nc) tvoe fielH=FF he<) 
IF RECETVED bad frame, 00 nothing BUT WAIT TO REC 
CHECK WHAT IS THE REQUEST FROM MHS SYSTEM. 

IF THE REQUEST IS 'D', CALL UPLOAD. 

IF THE REQUEST IS ’1', CALL DOWNLOAD. 



character*?^ 
character*?8 
i n t eqe r * 2 
i nteqer^^ 
int9qer*R 
i n c 1 u H e 
1 nc 1 u He 
hyt e 
b V t 9 
byte 



•nsql/' Receive successfully. '*/ 

'Dsqb/* UnrecoTnizeH ^ile tyoe. *'/ 

ioso(2) r fi 1 tvDe»ei<ec 
systi'T'e(2)» tiT»e(?) 
nicbao/ sysSqiowf sysBassinn 
*«-draO: fnossys.interlanlnibef.for' 

' ( SioHef ) ’ 
o a H ( 1 0 d ) 

Roackat(lS0),Tnaci<et(136) 

Hfi lnann ('4 0 )»sfi lna'ri('J 0 ),ft (31 



Assiqn a channel to NIAQt 

istet=sysBassiqn( ' ahaQ' / nicnan# , ) 
if(.not.istat) cell HbEstoo(%valfistet)) 



C Start uo and qo on line: 

istat= 3y5Saiow(»°:val (nichan)> 

1 %val(ioB<-setTioHe .or. ioSnestartuoIf 

2 iosbf/fff»»f) 

if(.not.istat) call libBstoc(Jivalfistat)) 
if(iosb(l).lt.O) call libBstoo(’4val(ioso(l))) 

C Receive incomino "nessaoe: 

150 tyoe *f' Ready to receive nessaoe ' 

istat=svsSqiow(/%val (nichen)» 

1 %va 1 ( i o E«-read 1 b 1 ic ) , 



2 


\OSO f • f 


5 


% 


reff'^oacket ) /%va1 ( 150) f 


if(. not. 1 Star) th 


en 


tvoe 


*/ ' 


Istat receive error* 


ao r 0 


1 0 




end if 


i f ( i o s b ( 1 ) . 1 t 


.0) 


then 


tyoe 


, ' 


VAX/VMS f'eceive error* 


qo t o 


1 0 




end if 


i f(iosb(2) .eq 


. 1 ) 

*» ’ 


then 


t /oe 


deceive block CRT error 


goto 


1 0 




end if 


if(iosb(2).eq 


.2) 

’ 


then 


tyoe 


Receive block alionment 


qot 0 


1 0 




end i f 


i f(iosbl2).ea 


.4 ) 


then 


tvoe 


* / * 


'^issinq receive clock* 


ao t 0 


1 0 




end if 


i f(iosb(2).ea 


.17) 

* » ' 


t n en 


t yoe 


DMA received block fail 


qo t 0 


1 0 




end if 
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type "deceived successfully.' 



C 



C 

C 

C 



C 



C 



C 



Assian destination address: 

T5acket ( 1 ) = ' 0?' x 
Tcacket(?)='07'x 
Toacket(3) = '01 'x 
Toacket('4) = '00'x 
Toacket (S)=Roacket ( IS) 

Toacket (6)=Roacket ( lb) 

Send acknowledge message: 

Assign type field: 

T6acket(7)='00'x 1 i no i cate tHat it is a ^essaoe 

Tpacket(A) = ’FF'x i acknowledge si anal 

°ut data into transnit cacket: 
i 

do i = 1 » 30 

Toacket())=icbar(n3ol(i:i)) 
i = i 1 

end do 

Transmit packet: 

istat=sysBaiow(>%yalfnicHan), 

1 %val(ioS<-writelglk), 

2 i OSD f f / 

3 ’^ref(Toac<etl»*4val(l3b)»»»/) 

if(iosb(l).lt.O) call lioSstoof'^valfiosofl))) 
type *f' Acknowledge is being transmitted ' 

Load transmit data and send: 

istat=svsBgiow(f%val (nichan) , 

1 %val(io<-<-ltds)f 

2 iOSOrfrrrrrr} 

if(iosb(l).lt.O) call libBstoo(%val(ioso(l))) 
if(iosb(2),ne.O) call libBstoo(%val(ioso(2))) 



Print out incoming messaoe: 
i =IP 

i f((Roacket(i ) .eo.ic*^ar( ' 1' ) ).or. 

1 (Roacket(i).eg.ic*^ar('i»’)))tnen 

do while ( Roac k e t ( i ) . ne . i c h a r ( ' / ' ) ) 
i = i t 1 

sfi lnam(i-lP)=Rgacket(i ) 
dfi lnam(i-ld)=P5oac<et(i ) 



1 

2 

3 

4 

5 



end do 

i f(( (Roacket (i-3) .eg. icnar( 'e' ) ) 

.or. (Roacket ( i -3) .eo. icherf '£ ' ) ) ) 
.and. ( (Rcacket( i-2) .eo.icbarf 'o' )) 
.or. (Roacker(i-2).eg.ichar('0'))) 
.and.((Rpacket(i“l).eo.icbar('d')'' 
.or. (Roacket(i"l).eg.icnar('0')))) 
exec ~ 2 1 EOD exec ^ 



else 

exec 



otner ■»xec 



end if 
m = i f 1 

do while ( Roac k e r ( T ) . ne . i c h a ( ' ' ’ ) ) 
ft (m-i )-Rpacket (m) 
m = m + 1 



^ h e n 
file 
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end do 

if ((ft(l).eci.ichar('t')).or. 
t (ft(l).ea.ichar('T'))) tnen 
f i 1 t V o e = 1 

else if ((^t(l).ea.ich 3 r('e*)).or. 

1 ( f t ( 1 ) . eo . i c h a r ( ' E ’ ) ) ) f'len 

f i 1 t y o e = 2 
else 

cal 1 send'nsgf.^oacicet ( 15) f-^oackar ( 16) / -nsoo) 
tyoe Uorecoqnized file tvoe.' 

goto 150 
end i f 

else 

do -yhi lefdoac’<et (i ).ne. ic6ar( ' ' ' ) ) 
i = i 1 1 

end do 

end if 

write(6» ll)(Roacket(i )» i = t^/i-t) 

11 forratC' *»<i>al) 

C CHeck the reouest Tiessaae: 

if (Roacket(lR).ea.ichar('l’)) then 
sfilnaTi(i-19)=0 

Call downloao(Roacket(15),Roacket(l6),sfi Inam, 

1 filtvDe»exec) 

else if ( Roac ke t ( 1 9 ) . eq . i c h a r ( ' 0 ' ) ) tnen 
dfi lna'n(i-19)=0 

Cal 1 uDload('^oac<et(15)fRDac<et (l6)»hfi loam, 

1 f i 1 t voe f exec ) 

end i f 
goto 10 
end 
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c 

c 

c 

c 



c 

c 

c 



C 



C 

c 

c 



SUB^^OUriNE D0i''‘JNL0A0(rlSfrl6fSfi Inannrfi Ityoer^xec) 
actual transfer .^ILE/niTERACTIVE. 

RETRANSyiT SA-1E FRAME IF NOT RECEIVE ACKNO/'LEDGE IN S 3FC. 

abort transmission if not receive ACKMO.^/LEDGE i: SEC. 



charact^r ^?8 

character^?? 

integer^? 

integer's 

1 nteaer*^ 

integer*^ 

integer*^ 

i n c 1 u e 

include 

byte 

byte 

byte 



tsq 2/* ^^o sucR file! Try anain. '*/ 

T>sn3/* Abort Transmission, '*/ 

i osb(2) / a do recount fdone 

filtyoe/exeCfmax 

nicran/ sysSaiowf sysSassi in 

sysShintimr sysTsetimr^ svsSwaitfr 

time(2)fSystime(2) 

*<-draO: [nossys.interlanlmdef.for’ 

* (liodef ) * 

oad(lOO) /sendrec(S12) fsendrec I ( 102^) 
Toac<et(lS6)fSfi Ina'^TUO) 

Roacket ( 150) , rlS^rlo 



Assign a c a n n e 1 to 'N I A 0 : 

istat=svs£assiqn( *NIA0* ^ni cEa^f ^ ) 
if(.not.istat) call libSstooCXvaHistat)) 



Printout: - - 

tyoe *f* Request transferring of file* 

Print filename: 

writef6f22)(sfi lnam(’<)^<=l^lS) 
format ( * * / 15a 1 ) 

tyoe to MOS system at adgress:02 07 01 00*^ 

1 r 1 5 f r 1 5 

Assign destination address: 

T oac ket(i)-*02*x 
Toacket(2)=*07*x 
Toacket(5)=*01 *x 
Toacket(^)=*00*x 

Get the address of reauestinq station: 

Toacket (5)=rl5 
Toacket (6)-rlb 

Assign tyoe field: 

Toacket (7) = *0F* x 

T oa c k e t ( 8 ) = • 0 0 * X 1 first trame 

Initialize f 1 a a : 
done - 0 



C 0 o e n file: 

ooenCname-sfilnam fUnit = lfOrr:janization=’s^auential ’ 
1 ftyoe=*old*fCarriaaecontrol=*list‘ferr=P) 



f» tyoe 


c H ec < 


oo i n t : 


if f f i 


1 tyoe. 


ej.l) then 


else 


CO t 0 


30 


end if 


ao f o 


aoo 
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c 

9 



C 

30 

33 

ao 



C 



C 



C 



c 



c 



Ooen file e'*ror Sen9lina: 

call sen o-DS g ( r 1 5 » r I 6 , Tis 3^ ) i no sucn file f nv again. 

tyoe * , ' no sucfi filel Try aaein.* 

return 

Send text fileJ 
count =0 

rean( 1 > 33, iostat = ios,end=100,err = 1 01 ) 

1 (toac<et(j),j=9,136) 

fornatC l<£Bal) 

roaci<et ( 1 35) = 'OA'x 1 <CP> 

foacket ( 1 36) = ’OO'x 1 <LF> 

istat=sysfqio»v( ,%val (nicBan) , 

1 % V a 1 ( i o 5 <- w r i t e 1 o 1 '< ) / 

2 i osb , , , 

3 ^ref ( roacxet ) ,%val ( 1 3b) , , , , ) 

if(iosb(l).lt.O) call lib'^stoo('4val(ioso(l))) 
iffiosb(2).ne.O) call libSstoo(’!ivalfio<ar)f.P))) 
tyoe File is oeinq trans^ritt^d.....' 

Load transmit data and send file: 
istat=svs3aiow(,’'Jval (nichan) , 

1 Xval(io^^l*’ds)/ 

2 iosOf, ,,,,,») 

if(iosb(l).lt.O) call 1ibl^stoDf%valfiosb(l))) 
ifOosbf2),ne.O) call libSstoof’-ivalfiosofS))) 

/Jait for 15 seconds and abort: 

istat=svsSbintim('0 zrlS.O'ftine) 
i f ( . n o t . i s t a t ) call 1 i o S s t oo ( % va 1 ( i s t a t ) ) 
istat=sys1)S9tiTr('Cval (2),%re^(tine),/ ) 
if(.not.istat) call libSstooC’-ivaHistat)) 

Wait for 5 second and retransmit: 

istat=sysSbintifn(‘0 rzS.O'^systim®) 
if(.not.istat) call lib5stoo(’'ival(istat)) 
istat=svs-3setimr(%val(l),%ref(systime),f) i «ait for 
if(.not.istat) call libSstoo(“4valfistat)) 1 5 sec. 

Peceive acknowledae: 

istat=svs5aio«(»%val(nicnan), 

1 %val(io3<-reaolb1k), 

2 i OSD , , » 

3 %reff^oac<et),%valfl50),,,,) 
if(iosb(l).lt.O) call libJstoo(’4'/al(iosb(l))) 
if(ioso(2).ne.0) call lib5stoof’<val(ioso(2))) 



Check the second tvoe field if = FP hex: 
if (Poac <et ( 1 b ) . ea. ' FF ’ X ) then 

call s vs Ucant i m ( , ) 1 cancel ri’^ers. 

Poacket(16)='00'x 1 clear flag 

i f ( done . e o . 1 ) ooto 50 

Toacket(B)=*01'x 1 middle frame 

ao t 0 3 0 

end i f 

if (count. ne. 2) then 

call sysSwaitfr(%val(l)) 

count=count+l 

goto 00 

end i f 

cal 1 sysSwaitfr(%val (2)) 
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i 



1 0 1 
c 

100 

c 

200 

222 

553 

500 

aoo 

C 

C 

C 



call sendmsT(rl5»rlb»'Tnsq3) ! aoort transmission 

tyoe ♦/' Abort transmission.' 
ret urn 

cal 1 1 ib$stoo(%val (ios)) 

Ass i in value to messaae of the last frame: 
do i = 'A , 1 3 o 

Toac ke t ( i ) = ' 32 ' X ! blam< cbar 

end do 

T oac k e t ( ^ ) = ' FF ' X 1 lastframe 

done = 1 

qot 0 40 

Send executaole filet 
if (exec.ei.l) then 

reao( I iostat = i os/end = F00/err = 202) 

1 (senarec(i)»i=i/5l2) 
format (5l2al ) 
m e X - S 

else if(e>tec.eo.2) then 

nead( 1 / 553/ i ostat=i os/end=SOO/orp=po2) 

1 (sendrecl(i)/j =1/1024) 
format ( 1024al ) 
max = 9 
end i f 
k = 1 
count = 0 
do 1 = 1/126 

if (exec. ea . 1 ) t n en 

Toacket(l+8) = sendrec('<ml26-(l?3-l)) 

else if (exec.eo.2) then 

Toacketn+B) = sendrecl(k*128-(126-l)) 
end if 
end do 

istat=sys5aiow(/5Cval (nichan)/ 

1 %val(io5<-writelol<)/ 

2 i osb / / / 

3 %ref(roacket)/%val(136)////) 

if(ioso(l).lt.0) call libSstoo(%val(ioso(l))) 
if(iosb(2).ne.O) call lioSstoo(%val(ioso(2))) 
tyoe */' File is neinq '■ransmitted ' 

Load transmit data and send filet 
i stat=sys So iow(/Xval (nichan)/ 

1 % V a 1 ( i o <- <- 1 t >3 s ) / 

2 iosD////////) 

if(iosb(l).lt.0) call libSstoo(%val(iosb(l))) 
if(iosb(?).ne.0) call libSstoo('ival(ioso(2))) 

'lait for 15 seconds and abort: 

istat=sysSbintim('0 :tl5. O'/time) 
if(.not.istat) call lib5stoo(%val(istat)) 
istat=sys5setimr(%val(2)/%re^(time)//) 
if(. not. i star) call lib5stoo(%val(istat)) 

%'ait for 5 second and retransmit: 

istat=sys3bintim( '0 ttS.O'/Svstime) 

if(.not.istat) call lib?stoo(%val(istat)) 

istat = sysfserimr(^val(l)/)iref(systime)//) 1 -vait for 

if(.not.istat) call lioSstoo(’4val(istat)) 1 5 sec. 
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c 



c 



202 

C 

500 



50 



Receive ac *c.now 1 edoe t 

ist3t=sys5aiow(^%va1(aicdan)f 

1 % va H i o Spread 1 b 1 k ) f 

2 \ OSb r > r 

^ /.ref (Roacket ) ,%va1 { 150) , , , , ) 

if(iosb(l).lt.0) call lib5stoo(’ival(ioso(l)l) 
if(ioso(2).ne.O) call lib»sfoo(’4val(ioso(2))) 



1 



Check 
i f 



the second tyoe field if - FF 
(^oacketCrS) .ea. then 

csll sys’^cantiniC,) » 

Roacket(l8)=*00*x i 

if(done.ea.l) noto SO 
Toacket (8)=*01 *x ! 

k - k + 1 

if (k.en.niax) then 
q o t vO 2 0 0 

else 

a o t o 5 0 0 

end if 



end if 

if (count.ne.2) then 

call sys5^aitfr(%val(l)) 
count^co'jnt + 1 
QO t o ^00 

end i f 

call svs?^aitfr(%val(2)) 
call sendmsn(rl5frlbfnsa5) 1 

tyoe Abor^* trans^^issi on.* 

return 

call lio$stoo(%val(ios)) 



hex: 

cancel 

clear 

n i dd 1 e 



abort 



t i T e ^ s . 
f 1 an 

f r 3 ^ e 



trensTission 



Assian value to message of the last frame: 

00 i =9 / 1 36 

Toac k e t ( i ) = * 3? ' X 1 olank char 

end do 

T oa c k e t ( 8 ) = * F F • X I last frame 

done - 1 

goto ^00 



tvoe */* Transmit comoleted* 

close(unit=l) 

ret urn 

end 
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i 



ooooooo 



SJBROUTI^IE UPLOADCrlSf rlb^rjfi Inannr 1 tyoe/exec ) 



C 

aa 

c 

c 



actual RECEIVTvjG OF FILE. 

OrSCARO last FRA.viE. 

CHECK P^OR 1 RECOP^D FILE. 

SEND back ACKNO'/J ledge ^SG.(<?nd t-yne fi’eli = FF nex). 

IF RECEIVE RAD FRAME, DO MOT-‘i:^G 8UT /'AIT TO RFCET/E 
SAME FRAME AGAIN. 



c^taracter ^25 

character*23 

c^>af'acter ^23 

1 nteqer*? 

inteaer*^ 

include 

include 

byte 

byte 

byte 



' • / 
' • / 



Tisal/* Received succ ess t u 1 1 v . 
nsa^/* Qoen file faill Trv ^aain 
TisnS/* Tyce "sendfile FM.FT'*, '*/ 
ioso(2) ,done, fi 1 tyoe,exec,nax 
nichan, sysSaiow, svsTassinn/recsize 
*<-dnaO! [nossvs.interlanlnidef.for' 

* ( B i o d e f ) * 

oad( 10 0) ,detr9cT51 2) ,qet ''«cl ( 1 0 2a) 
RoacKetllSOj/n^ilpa^C 
Toaci<et(13o),rlb, rlo 



Ass inn a channel to NIAO: 

i stat=sysBassign( '-JIAO' ,nicnan, , ) 
if(.not.istat)’call 1 ibBstoof^val (istat)) 

^rint outr 

tyoe Request neceivina of file* 

^rint filename^ 

w r i t e ( 6 # ^ a ) ( d f i 1 n a na ( k ) , k = I , 15) 
f OPT^at ( * * , 1 5a 1 ) 



tyoe *,* from M03 system at adnress 
I r 1 5 , r 1 o 

Initialize f I a g : 
done^O 



0 2 0 7 0 1 0 ) ' , 



Oetermi n* 



?cord size ov file tvoe 



if (filtyoe.eo.l) 


t non 






r ec s i ze = 


1 


1 t ^ X t f i 1 ^ 


else if 


(exec .ea. 


11 t n e n 






r e c s i z e “ 


SI 2 


1 executable 




max “ 5 






else if 


(exec . eo . 


2 1 t ^ 9 n 






r e c s i z e = 


1 0 ? a 


1 EOO exec f 




max ” 9 






end i f 









Ooen new filet 

if (filtyoe.en.2) then 

ooen(name=dfi Inao/uni t-2, 

oroanization^'seouen^ial ’ f 
tyoe-*nev' ,carri aaeconrrol^' 1 
iostat=ios,err=7^ 
record si ze^recsi ze, recorafvoe 



1 

2 

3 

a 

else 



1 3 f 



1 

2 

3 

end if 



oo‘^n{name = dfi Inam^uni t=2, 

oroaoization^'sequential *, 
tyoe='nev^' ,carri aoeconr rol 
iostat=ios/err=7) 



:ed ' ) 



1 s t 
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goto *^0 

cal 1 sendmsa(rl5/rlOf7isg«^) 

tyoe Ooeo file fa ill Try ^aain* 

return 



C Peceive filer 

90 call sendmsg ( r 1 5 f r 1 6 / TisnS ) 

type Send instruction '^essaoe.* 

tyoe Peady to receive file * 

k = 1 

20 istat=sys£qiow(/%val Cnichan)^ 

1 %val(ioT.^readlblk)^ 

2 1 oso / f / 

3 %refCPoacket)/%val(lSO)/^^^) 

if(iosb(t).lt.O) call 1 ibBstoo(’'<val (iosbfl ))) 
if(iosb(2)«ne.O) cal 1 1 ib.t>st'^o(‘'<val (ioso(2))) 

if (Roacket(lb).on,*OF*x) tnen 1 a 1 record file 
w r i t e ( 2 / S S ) ( P o a c k e t ( i ) o* = 1 ^ / 1 '■! b ) 

55 fornatClPdal) 

done= 1 

else if (Poac‘^et(lS).en.*^F*x) rnen 
done= 1 

end if 

C Send acknowledge messaae: 

C Assign destination a ci dress: 

60 TDacket(i)=*02*x 

Toacket(2)=*07*x 
Toacket(3)=*01*x 
Toacket (^)=*00*x 
Toacket (5)=rl5 
Toacket (6)=rlb 

C Assign tyoe field: 

Toac ket ( 7 ) = * 00 • X I n^essaoe 

Toacket(8)=*FF*x 1 acknowledge signal 



C 



Put data into transnit nac<et: 
do i = 1 f 2 3 

Toacketf j) = ichar(nsal(i :i)) 
i = i M 

end do 



C Transmit packet: 

istaf=sysSQiow(f%val (nichanK / 

1 *'ival(ioT«-writelDl<)f 

2 i o s b / f f 

5 %ref(Toacket)/%val(lS6)#f//) 

if(iosbCl).lt.O) call 1 inT>stoo(%valCioso(l))) 
if(iosb(2).ne*0) call libistOD('^valCiosoC2)l) 
tyoe Acknowledae is beino transnir^ed.... 

C Loaa transmit '^iata and send: 

istat=sysSaiow«i(/%val (nichan)/ 

1 % V a 1 ( i o 1 t is ) r 

2 ioso/ff/f^f^) 

if(iosb(l).lt.0) call libSstoo(%val (ioso(l))) 
i f(iosb(2).ne*0) cal 1 1 ih3stoo(%val Cioso(2) )) 

if ((done. eg. 1) •and* (k.ne.max) .and. 
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1 (filtyoe.eq.2).and. (exec.ea.l)) t^en 

write(2/S5S)(aetrec(i)f i = lf(128*(k-l))) 
QO t o 7 0 

else if (done.eQ.l) then 
qo t: o 7 0 

end i f 



C 



S55 

777 



666 



*irite to record every after receivincj '4 or ^ fra-^es: 
if (filtyoe.ea.2) then 
do 1=1/128 

if (exec.ea.l) then 

aetrec('<*l28^(l?8-l ))=Roacket(ltl8) 
else if (exec. e a. 2) then 

aetrecl (k^l2B-( 128-1 j )=Roacket (1 
end if 
end do 
k = k 1 

if (k.eo.-ria*) then 

if (exec.eo.l) then 

wri te(2/S55) (aetrecCj )/ j = l rrecsize) 
for-nat (512 a 1 ) 
else if (exec.eo.2) ^hen 

write(2/777)(qetrecl M)/j=l/recsize) 
forTat ( 102 4 al ) 
end if 
k = 1 
end if 

else if (filtvoe.ea.l) then 

write(2/666) (Roacket( i ) / i=l^ / 146) 
fornat(128al) 

end if 
ao t o 20 



70 close(unit=2) 

tyoe */ * Receive comoletedi’ 

return 

end 
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c 



c 



c 



c 



c 

80 



c 



c 



SUB•^OUTI^JE SEMD’>iS6(r 15, rl6,-^sa) 

ACTUAL SENOI^JG OF viESSAGE. 

,vAIT FOR ACKUO/lLEDGE . 

IF NOT ACKNO.'iLEDGE TN 5 SEC, PE T » A NS'^ I T . 

IF NOT ACKNO^iLEDGE IN 10 SEC, ABORT TR A N 3M I 3S I OM . 



character*!*) 
i n t eae r * ? 
inteaef**^ 
i n t eae ^ 

i n t eqe f' * ^ 

include 

include 

byte 

oy t e 

byte 



Tisa 

ioso(8) ,addr, done, count 
nicHan, svsSaiow, sysTassian 
sysBbintin, sysTseti-nr, sysS«aitfr 
svst^■ne(2),^iTe(2) 

*«-dpa0: {nnssys . interl an) nioef . for ' 

' ( 5 i o 8 e f ) ' 
o a d ( 1 0 6 ) 

Toaci<et ( 1 86) ,te<t ( 1?3) ,Roac<et ( ISO) 
r 1 5 , r 1 6 



Assign a c*^annel to "ilAO: 

istat=svsBassiqn( 'NIAO' ,nicnan, , ) 
if(.not.istat) call lib5ston(%vaHistat)) 



Assign destination address: 
TDacket(i)='02'x 
Toackat ( 2) = ’ 07 ' x 
Toacket(3)='01'x 
Toacket (d)='00'x 
Toacket (5)=rl5 
T oac ket ( 6 ) =r I fa 

Assign tyoe field: 

Toa c k 9 1 ( 7 ) = ' 0 0 ' X I "nessaae 

T oa c k e t ( 8 ) = ' 0 0 ' X I don't care 



Put data into transmit oacket: 

i . 

do 1 = 1,28 

Toacket(j )=ic6ar(msq( i :i )) 

} = j M 

end do 

Transmit oacket: 

c oun t =0 

istat=sysFqiow( ,%val (ni cfaan) , 

1 %val(iot^-writelolk), 

2 i osb , , , 

3 %ref(Toacket),%val(13fa),,,,) 

if(iosb(l).lt.O) call libistooT’^vaHiosofl))) 
if(iosb(2).ne.O) call 1ib£stoo(%val(iosn(2))) 
tyoe *»' '■’essaqe is beina transmitted ' 

Load transmit data and send; 

istat=sys5aiow(,''ival (nicnan), 

1 %val(ioi"^ltds), 

2 iosb,,,,,,,,) 

if(iosb(l).lt.O) call libSstoo(%val(iosb(l))) 
if(iosb(2).ne.O) call 1ib8stoo(’<val(iosc(2))) 

A' ait for 15 seconds and abort: 

call sysSbintimC'O ::lS.0',tiTe) 
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cal 1 svs?seti7^r(%val (2)/%ref(ti'r>e)f/) 



C 

C 



C 
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/vait for 5 ‘Second and retransmit: 

call svsSointim(*0 ::6.0*,systime) 

cal 1 svsSsetimrC’^ival (l)#%ref(svstime)f/)!ret*rans'T^it 

laftar 5 sec 



Receive acknowledae: 

istat=sys5aiow(f%val (nicHan), 

1 “'^val(ioS^readlblk)/ 

2 i o s b f / , 

5 %ref(Rpac'<et)/%valCl50)/,/^) 

if(iosb(l).1t.O) call lio?stoo(%val(ioso(l))) 
if(iosb(2)-ne.O) call lib?stooC%val(ioso(2))) 
Check the second tyoe field if - hex: 
if (Roackef(lB).ed.’FF*x) then 
i = 

do while (Roacket(i),ne.ichar(*'')) 
i = i t I 

end do 

write(of6o)(Roacket(j)f i = l^/i-l) 
formate' *^<i>al) 

call sys'l^cantimC , ) I cancel timers 

RcacketCl^l^'OO'x 
r e t u r n 

end if 

if (count#ne*2) then 

cal 1 sysSwaitfr(%val (1)) 
count=count tl 
QO t o 8 0 

ena if 

call sys?waitfr(%val(2)) 

ret urn 

end 
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APPEHWX D 

VAX/¥BS-MDS ETHBBNET ICCAL COHHUHICATIOH NETWORK USER MANUAL 
GENE F AL : 

ETHERNET is a pxcgram that will allow an individual tc 
transfer a message cr a file between VAX/vms and the MDS 
Sysrem. After this program is executed on one of the 7AX/VMS 
terminals, a user can leave the terminal and operate only on 
the aCS System terminal until he wants to disconnect the 
communication. 

The user can execute this program only when he has 
LO G IC priv ile ge. If any problems occur while executing the 
program, user can contact one of the following VAX/VMS 
professional staff: 



SPECIFIC : 

ETHEBNET.EXE program resides on the VAX/VMS under public 
user acccunt with user name "INTERLAN” and password '•VMS”. 
Any user can copy this file by typing in the fcllcwing 
comma nds : 



The user should also copy file ETHER1.EXE which should 
be executed after finishing the file transfer process in 
order tc clear both transmit and receive buffers. 



Albert Wong, Sp505, x2455 
Olive Paek, Sp525b 
Jeanne Bowers, Sp525a, x2168 



SCcpy <CR> 
SFrc m: 

$To: 



^dral :[ i nterlan ]ethernet . exa <CR> 
* <CR> 
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When these two files are copied, user can execute 
ETHEPNET.EXE by typing 

5r ethernet <C8> 

then the message 

Heady to receive message 

will appear cn the screen which tells the user that VAX/VMS 
has been ccnnected to the Ethernet Local Area Network. 
After rhis point the user can do any file or message 
transfer by working cn the MDS Sysrem terminal. 

QN MDS ^siEM: 

At the time this thesis is being written, there are 2 

diskettes which contain program used to do file and message 
transfer between MDS System and VAX/vms, one diskette is to 
be used with the MDS System which is connected to the single 
density disk drive and it contains the following programs: 

LOGON1.COM 
SENDMSG1 .COM 
SSNDFIL1.COM 

the other is to be used with the MDS System which is 
ccnnected tc the double density disk drive and it contains 
the following programs; 

LOGON2.COM 
SENDMSG2. COM 
SENDFIL2.COM. 

These twc diskettes are now being used by Capt. Mark Stctzer 
USMC, the originator of the programs in the diskettes. 
Therefore, the final instructions on how to use the programs 
will be found in his thesis which will be completed by 
September 1S83. However, the instructions on how to trans- 
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fsrs file ci messages between the MDS System and '/AX/yyiS are 
as fellows; 

When the system is booted up winh the above mentioned 
diskette, execute LOGCNI.COa (or LOGON2.COM if you work with 
the double density disk drive) by typing 

a>L0G0N1 <CR> 



To transmit a message from the MD S System to the V^X/VMS; 
A>SJKDM^1 <CR> 

ETHERNET CONSOLE MESSAGE TRANSMIT PROGRAM: 

VERSION 1.11-SINGLE DENSITY; 06/10/83-MDS 

NCTEzPECGRAM "LCGONI" MUST BE LOADED PRIOR TO 
RUNNING THIS PRCGRAM FCR PROPER OPERATION. 

IF NCT-COLD BOOT AND TYPE "LOGON 1" AND 
THEN INVOKE THIS PROGRAM. 



SELECT NET ADDRESS OF DESTINATION: 
ADDRESS 00-04-0 A { MDS SYSTEM ) .-ENTER 1 
ADDRESS 00-03-EA( MDS SYSTEM ): ENTER 2 
ADDRESS 00-07-7F( VAX 11/780 ):ENTER 3 

3 



INPUT MESSAGE (128 CHAR MAX) -END WITH ACCENT=>' 



fSlil he re . ^ 



SENT 



A> 

To transmit a file fr^ your A to VAX/VM S; 

Initiate SENDHSG like you want to transmit a message as 
above. Eut this time you must enter the special message as 
shown belcw: 

A>SEND MSG 1 ^H> 
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INPUT KESSAGE(128 CHAR MAX) -END WITH ACCSNT=> ' 
af i lgname . fil et v p9/tx t * 

SENT 

»♦**=»*«♦♦* RECEIVED MESSAGE IS : 

Type "sendfile EN.FT” 

♦**♦♦♦***♦ END CF MESSAGE 

CCNNECTED TO THE ETHERNET-COLD BOOT TO DISCONNECT 

A>SEND EIL 1 fi lename . fi letype <CR> 

ETHERNET FILE TRANSFER PROGRAM: 

VERSION 1.12-SINGLE DENSITY ; 06/10/83-MDS 

NOTE:FCE PROPER OPERATION, PROGRAM ''LOGON1'* 

MOST BE EXECUTED FIRST TO LOAD THE INTERRUPT 
HANDLER INTO MEMORY. IF NOT-COLD BOOT AND DO SO 

SELECT NET ADDRESS OF DESTINATION: 

ADDRESS 00-04-0A (MDS SYSTEM) : ENTER 1 
ADDRESS 00-03-EA (MDS SYSTEM) ;ENTER 2 
ADDRESS 00-07-7E (VAX 1 1/789) ; EN TER 3 



IS THIS A TEXT FILE [52.5KB MAX] ( Y OR N ) ==> 

Y 

READING THE FILE INTO THE BUFFER... 

READ COMPLETE 

*«*♦**=»*** FILE TRANSFER BEGINS ♦**♦*♦#*«* 

IX 
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TX 



FILE TRANSFER COMPLETED ********** 

A> 

52 receiv e a file from VAX/VM S to your disk ; 

Initiate SENDMSG like you want to transmit a message as 
above. But this time you must enter the special message as 
follcw: 

A>SENEMSGJ <CR> 



INPUT BESSAGE(128 CHfiR MAX) -END WITH ACCENT=>' 
! filer ame.filet Ype /ex€^ 

SENT 

file receipt begins ********** 

OPENING receive FILE: RECFROMX.NET 

EX 

RX 



***** euD file RECEIPI-SEE FILE RECFROMX.NET ♦**** 

CONNECTED TO THE ETHERNET-COLD BOOT TO DISCONNECT 

A> 

Note: Except for line spacing, the above sequences appear as 
they will at the MDS System terminal. The underlined items 
are those which you must enter (in proper sequence) . 
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Important nct9: 

1) Dc not forget to end any message sent to the VAX/VMS 
with accent 

2) The ”/txt” is used to indicate that the file to be 
transferred is a text file. The "/€xe" is used to indicate 
that the file to be transferred is an executable file. User 
must specify this indicator correctly to yield the 
successful transferring of a file. 
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APPENDIX S 

SYHBOLIC NAME FOR Nil 010 CONTROLLER COMMAND CODE 



This Appendix lists all NIDBIVER QIO function 
NI1010 Ethernet Controller User Manual contains 
description of the NI1010 controller command 
status returns. 



codas. The 
a complete 
codes and 
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NIDt-F.FOR - symtioHc names for MI 1010 control ler command codes 
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APP^DIX F 

8ICBIVER FONCTION AND STATUS CODE SUMMARY 

This Appendix lists all NIDFIVER QIO function cedes and 
lOSB status codes for each. The list of lOSB status does not 
include standard VAX/VMS error codes for device-independent 
errors. 

The NI1010 Ethernet Controller User Manual contains a 
complete description cf the SI1010 conrroller command codes 
and starus returns. 



Sy mb olic 
■Pu net ion 
Code 



10$ SETMODE! 
IO$T! STARTUP 
10$ 3ETMCEE! 
I0$H SHUTDOWN 
10$ PEADLELK 
IO$“READPELK 
IO$“WRITILBLK 
IO$”WEITEPELK 
I0_;SBILM 

10 SILM 
10 CIM 
10 SFRM 
10 CPRM 
10 SEOEM 
10 CROEM 
10 OFFLINE 
10 ONLINE 
10 ROBD 
10 HRS 
10 HCDI 
10 SHB 
10 LTD 
10 LTDS 
10 LGA 
10 DGA 
10 FEBQ 
10 RESET 



Control ler Function 

Go Online 
Go Offline 



Supply Eeceiv 
Supoly Eeceiv 
Load Transmit 
Load Transmit 
Set Module In 
Mo de 

Set Internal 
Clear Icopbac 
Set Prcmiscuo 
Clear Promise 
Set receive-0 
Clear Receive 
Go Offline 
Go Online 
Run On-board 
Report and Re 
Report Collis 
Supoly Eeceiv 
Load Transmit 
Load Transmit 
Load Greup Ad 
Delete group 
Flush receive 
Reset 



€ Buffer 
e Buffer 
Data and Send 
Data and Send 
terface Loopback 

Loopback Mode 
k Mode 

us Receive Mode 
uous Receive Mode 
n-Error Mode 
-On-Error Mode 



Diagnostics 
set Statistics 
ion Delay Tine 
€ Buffer 
Data 

Data and Send 
dress (es) 
Address (es) 
BAR/BCR Queue 



Po ssi ble Contents of 
'Se con dIT7SB~X onq word 
ir~sX adus is 
BB$"NORflA LlTn octal ) 



0 

0 

0 (see note 1) , 17 
0 (see note 1) , 1 7 
0 ,1,3, 5, 6, 10, 17 
0,1,3,5,6,10,17 

0 
0 
0 
0 
0 
0 
0 
0 
0 

See note 2 
0,17 
0 ,17 

0 (see note 1) ,17 
0,5,17 

0,1,3-5,6,10, 17 
0,5,li,17 
0,5, 12,17 
0 

See note 2 



note 1; The STATUS byte of a received packet will contain 
nene or more of the following octal error codes: 

1 CRC error 

2 alignment error 

4 1 or more packets were previously missed 

or it will contain: 
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(Ji4:rLOKJ-AO 



17 



note 2: 



Non-existent memory timeout on some buffer 
word (other than the first) occurred while 
DMAing the received packet into memory 

The second lOSB longword at the completion of -his 
command will contain one of the following 
diagnostic codes: 

success 

checksum error in local memory 
NN10 DMA error 
transmitter error 
receiver error 
loopback failure 
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